






HTML lite 


A Wireless Markup Language 
v.Niele ET 





sp - 


K 


Farkasokkal 
8. oldal 


ISSN 15845185 


11101K 


9771586"518 


2002 Január / 


2002 Január 


HTML líte 


A Wireless Markup Language 

Egy vérbeli informatikus mindenekelőtt hidegrázást kap a csigalassú, 

legfeljebb kétszintű grafikával (ha egyáltalán...) ellátott, 4-5 sorban, soronként 
20 karakterben megjelenített szolgáltatásoktól, amit ráadásul rendes billentyűzet 
hiányában mindenféle trükkös módon lehet csak használni. Kínszenvedés az egész. 
A WAP halálra van ítélve, mondjuk kórusban. Aztán a kezünkbe kerül az első WAP- 
os telefon... 


Farkasokkal táncoló 


(III. rész) 


Az előző alkalommal sikerült telepítenünk a fürtszolgáltatást, most 
megismerkedünk az adminisztrálására szolgáló mmc-modullal, a parancssori felü- 
lettel, a csoportokkal, a függőségekkel és az átköltözés rejtelmeivel. 
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Ki mivel p? 
Farkasokkal Netmonozó 
Emlékeznek még a ... típusú nyomtató esetére, mely beállt a fürtbe? 


Azt a cikket Lepenye Tamás követte el, a NetMon sorozatba , furakodva". 
Most pedig én fogok az ő szakterületébe belekotyogni egy fürtküzdelem kapcsán. 


RIS General] Operating System] Memberot ] Los 


Managedgy  ]/ Obiect ]/ Secuity Remote! 


(III. rész) PA. Youcan manage this remote instalalion server and contto 


ZÁ vayiintetacts with existing and potential cent computert 











A mai alkalommal a RIS kiszolgáló beállításait nézzük végig. fOdeÁeyjöt eses TÉRT EZN 
A RIS összes felügyeleti szerve be van építve az Í F7 Hegpondio cieri computers rogvest vervésd 
Active Directory Users and Computers MMC snap-inbe, [7 MS nalréspond to igknanm elért comoiáátt 17 e 
így ezzel a megszokott eszközzel (szinte) minden esek see ZET ÉSEET 
RIS-karbantartási feladatot elvégezhetünk. Jövése szerte petét ák TÁG GR Ó pets zS EJB 
! "encountered they wil be fixed. 


/ This option is only available írom the server console. 


Verifv Server 


A Windows NT 
és a Windows 2000 
memóriakezelése ) " SPAM 


— más megközelítésben (olvasói levél) — Jó vagy rossz? 
Lehetséges válaszok 

A spam mibenléte, az erre vonatkozó eddigi, jelenleg hatályos 

illetve a mindjárt hatályba lépő szabályozás alapos áttekintése megérdemel annyi 

energiát az olvasótól, amennyit az elolvasása igénybe vesz, mivel a 

jogi megközelítés változása igen tanulságos az Internet jogi szabályozásának egészét tekintve is. 
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Bi Local Security Settings 
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Portszűrés IPSec-kel 


ree] [FSC SEaar 

Bzevsam feddent (Respond ony) Munkánk során sokszor kerülünk olyan helyzetbe, 

E EA ét ez on memesset hogy egy kiszolgálót (legyen a feladat web, levelezés vagy bármi más), 

§ B esszel ákes ATSGÁTASZÍT] meztelenül, pőrén kell az Internethez csatlakoztatni. Sehol egy jó kis tűzfal, 





Create IP Securty Polcy marad az önvédelem. Az már alapszabály, hogy minden szolgáltatást, portot, 
Manage IP fiter ists and fiter act. sgaar si 3 k. a 
Esek amire nincs szükség, be kell zárnunk, de mégis, hogyan? 


EL ekét ASP Suli 


Az Indexing Service 
Az Indexing Service szolgáltatás - mely a háttérben 
csendben indexelgeti a dokumentumok tartalmát 























EALEHESZETTTEZTNI Dia 
Ele View Help (hogy később azután segítségével kereshessünk közöttük) 
ey resT -megtalálható a Windows 2000 -minden változatában. Ha a szolgáltatás fut, 
MIBE SSAASESŰ még az egyszerű keresés is felhasználja az Indexing Service-től 
EI tor: void) ges kapott adatokat, de programozói felületének köszönhetően 
KELSZ nagyszerűen használható scriptekből is. 
joesztíztákei e 
E sze Sza et kE HJA 
ET Akadémi 
e ademla 
(I. rész) 
Új év, új sorozat. Elérkezett az idő itt Magyarországon is, hogy belevágjunk 


egy ki tudja milyen hosszú ideig tartó kalandba, és feltérképezzük a .NET szövevényes világát. 
A .NET-ről, mint fejlesztési háttérről már írtam egy bevezetőt a Tech.net 2001. júniusi számban. 


Aki még egyáltalán nem találkozott a .NET-el, annak ajánlom a cikket elolvasásra, 
XMLgessünk 


mert az abban leírtak ismeretét már alapul veszem ebben a részben. 
































BA (IX. rész) 
Feso  F Az előző részben láttuk, hogyan kell használni az 
fm emoloyeető XmlReader és az XmlWriter osztályokat. Gyorsak, de eléggé alacsonyszintű 
 koárodpate Order Detaits interfészeket adnak a kezünkbe. Most megnézzük azokat a technológiákat, 
Fele eásáte [ee ezett amelyek rájuk épülnek, és a segítségükkel így jóval fejlettebb módon is tudunk 
telnet, Gst xml dokumentumokat manipulálni. A főszereplők a DOM, az XSLT és az XPath lesznek. 
Hz — I idz 
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SOL Server 


Join algoritmusok 

Az elmúlt alkalommal megvizsgáltuk a Ouery Optimizer működésének 

főbb alapelveit, és kiveséztünk néhány egyszerű végrehajtási tervet (guery plan). 
Most - ígéretemhez híven - a kapcsolási, avagy join stratégiák kerülnek sorra. 
Joggal kérdezhetik, hogy minek ez nekünk, hisz mindig minden automatikusan 
dől el az SOL Serverben. Ez igaz. De hogy milyen döntés születik automatikusan, 
azt súlyosan befolyásolhatják a mi korábbi tervezési döntéseink. 





MSDovwnload 


— Patchwork 

2001 október közepétől a Netacademia Kft üzemelteti Magyarország 

egyik legnagyobb letöltőközpontját. A Microsoft Magyarország megbízásából 

elkészült oldalak az eddig megszokott tartalommal, de eltérő formában jelentkeznek. 

Az új megjelenés könnyű kereshetőséget, világos áttekinthető formát biztosít 

a látogatók számára. Az innen letölthető programok közül csemegézünk ebben az új rovatban. 
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Rendszerváltás 
IPvó 


Csak semmi aggodalom! Most nem hullanak fejek, nem cserélik le az utcatáblákat, és azt sem írják elő, 
hogy hány ágú, milyen színű csillagokkal díszíthetjük a karácsonyfát. Szerencsére másról, sokkal érdekesebbről 
és hasznosabbról lesz szó: az Internetről. Helyesebben annak gyakorlatilag egyeduralkodó 
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Design Time 


Eljött a január, a fogadkozások és jóslatok hónapja. Idén nem jósolok, és 
nem is fogadkozom - a cím mást sejtet. Az újévi fogadkozások valójában 
nem mások, mint életünk átszervezésének feledésbe merülő kísérletei. Mi, a 
tech.net magazin szerkesztősége, fordítva csináljuk. Nem fogadunk meg 
semmit, ennek azonban látható jelei lesznek. Az ojság némiképp átszerve- 
zett dizájnja a mementó: valami megváltozott! De mi? 

A körülöttünk lévő világ. Amerika megtanulta: a legjobb mentési stratégia 
sem ér semmit, ha hiányzik az az emberi munkaerő, amely a halott adatok- 
ba életet lehelne. Minek állítsuk vissza a WTC alá temetett adatokat, ha 
nincs, aki értelmezze? A nagy cégek többé soha nem fognak arra töreked- 
ni, hogy többezer dolgozójukat ugyanabba a buildingbe költöztessék. 
Hogy mi köze ennek az informatikához? Fenntartja a fejlődést még recesszió 


közben is. Ide nekem a videokonferenciát, a nagy, és még nagyobb sávszélességű kapcsolatokat, hogy 
a földrajzilag szétszórt telephelyek dolgozói legalább virtuálisan együtt legyenek! Mi kell ehhez? A te- 
lephelykapcsolat legyen - költségtakarékos módon - Internetkapcsolat. Ha Internetkapcsolat, és biz- 
tonság, akkor virtuális magánhálózatok. Ha virtuális magánhálózatok, akkor titkosítás és hálózati is- 
meretek. Ha hálózati ismeretek, akkor IP, IPv6, útválasztó protokollok, RRAS. Ha titkosítás, akkor 
IPSEC, Kerberos, Encrypting File System, Public Key Infrastructure stb. Nem mondhatjuk, hogy a mi kis 


Nem fogadunk meg 


semmit, ennek 
azonban látható 
jelei lesznek. 


Az ojság némiképp 


átszervezett 


dizájnja a mementó: 
valami megváltozott! 


De mi? 


vindóz barátunk nem készült fel jó előre erre a változásra. Mondjuk ki: 
ez a recesszió nekünk, informatikusoknak még jól is jöhet. Persze csak 
azoknak, akik valamivel előrébb járnak, mint társaik, mert ha a recesszió 
eléri a hagyományos iparágakat, a hagyományos rendszergazdik sem 
lesznek védve. A kiemelt tudású szakemberek viszont igen. 


2001 

Hadd számoljak be most a tech.net magazin elmúlt egy évéről. Tizen- 
három szám jelent meg, összesen közel hatszáz oldalon. Előfizetői tá- 
borunk töretlen lendülettel növekedett, kiadott példányszámunk de- 
cemberre elérte a négyezret. Hogy ez Magyarországon mekkora szám, 
azt jól illusztrálja, hogy a közelebbről meg nem nevezett, ámde egyet- 
len számítástechnikai hetilap is ebben a példányszámban jelenik meg! 
Az eredeti gondolatmenet követésével nullára redukáltuk a töltelékin- 
formáció mennyiségét: 


Megszűnt a hírek rovat, mert egy kéthónapos átfutású lapban ennek helye nincs. Van az Interneten 


annyi de annyi portál, melyek annyi de annyi haszontalan hírrel bombáznak minket! 

2 Megszűnt a külső lapokból átvett cikkek ócska hagyománya. Ma már minden cikket a szerkesztőség 
munkatársai írnak. Rá kellett jönnünk, hogy a külföldi cikkek annyira távol állnak a magyar ,vir- 
tustól", hogy tripla munka van velük. Le kell fordítani, majd kiszedni belőle az eredeti mű tárgyi 
tévedéseit, és végül stílust adni neki. Mindeközben néhány esetben többet tudtunk az adott té- 
máról a cikk eredeti szerzőjénél. 


8 


A sorozatok szinte tankönyvjelleget kölcsönöznek a lapnak. Új előfizetőink nemegyszer visszamenő- 


leg az összes számot megveszik. El sem tudom mondani, mennyire szívet melengető, amikor va- 
laki még az irodánkba is kicaplat, hogy mielőbb elvigye a kék-ezüstöt. 
A töltelékinformáció megszűntével azonban a lap - bármennyi pici humort fecskendezünk is bele - 
súlyos olvasmánnyá vált. Gondoljunk csak az XML sorozatra! 
Tulajonképpen emiatt alakult át a lap belső felépítése olvastatóbb, zaklatottabb formátumúvá. A kék 
színárnyalatát pedig az ,idők szavára hallgatva" változtattuk meg. Its XP time! 


Fóti Marcell 
marcellf onetacademia.net 


working with windows / 





tech.net 


working with windows 


Szerkesztőség 
Főszerkesztő: Főti Marcell 
fronetacademia. 





Főszerkesztő-helyettes: Fülöp Miklós 
mick(2netacademia.net 
Szerkesztőség címe: 

1105 Budapest, Ihász utca 13. 

Tel.: 263-2732 
technetOnetacademia.net 
Nyilvános levelezési lista: 


tech.net€technetklub.hu 


Kiadja és terjeszti a 


NEtACADEMIA 


A LEGJOBBAKAT TANÍTJUK. 


NetAcademia Kft. 

Terjesztési, előfizetési információ: 
Tel.: 263-2732 
terjesztes(oOnetacademia.net 
Megjelenik havonta, ára 1.344 Ft 
Példányszám: 4.000 


NetAcademia € Copyright 2002 
Minden jog fenntartva, beleértve 
(a részleteket illetően is) a 
sokszorosítás, a nyilvános előadás, 
fordítás jogát. A magazinban közölt 
cikkeket, képeket és illusztrációkat 
a kiadó engedélye nélkül közölni, 
reprodukálni tilos. 


Előfizethető megrendelőlevélben a 
szerkesztőségnél: 
1105 Budapest, Ihász utca 13. 
Fax: 261-7145 
cl li S 


Hirdetésfelvétel: 


BÁRSONYKALAPÁCS 


cé 
Felelős: Balogh Zoltán 
Tel.: 489-4665 
Fax: 489-4660 
infoDve 
1027 Budapest, Fő utca 67. V. 1. 
Grafikai tervezés, kivitelezés, 





átüté stker kovácsa , 


nyomdai előkészítés: 
Bársonykalapács Marketing 
Művészeti vezető: Balogh Zoltán 
Bársonykalapács 6 Copyright 2002 


Nyomda: 
Cerberus Kft. 

1066 Budapest, Lovag u. 14. 
Felelős vezető: Schmidt Gábor 


ISSN 1586-5185 


SÜ0: Ü4: 


. Farkasokkal 


táncoló ut. rész) 


Az előző alkalommal sikerült telepítenünk a fürtszolgáltatást, most megismerke- 
dünk az adminisztrálására szolgáló mmc-modullal, a parancssori felülettel, a 
csoportokkal, a függőségekkel és az átköltözés rejtelmeivel. 


A Cluster Administrator 

A telepítés befejezése után a start menü , Administrative tools" 
csoportjában megjelenik a ,Cluster Administrator" ikon, amely 
grafikus felületet nyújt a clustererőforrások kezelésére. Ha a ki- 
szolgáló konzolja helyett előnyben részesítjük a saját munkaál- 
lomásunkat a rendszer konfigurálására, akkor telepíthetjük az 
Advanced Server CD-ről az 4386 könyvtárból az Adminpak.msi 
csomagot. Ez a Windows 2000 Server valamennyi szolgáltatásá- 
nak kezelőprogramját telepíti Windows 2000 munkaállomásunk- 
ra. NTá-re a csomag sajnos nem telepíthető. 

Első indításkor meg kell adnunk a cluster nevét, hogy csatlakoz- 
hassunk hozzá, de a lehetséges neveket fel is fedezi a modul, ha 
megkérjük rá. A következő alkalmakkor már automatikusan csatla- 
kozik a megadott clusternévhez. Ha ezt nem szeretnénk, akkor a 


cluadmin -noreconnect 


vagy 


cluadmin -norecon 


kapcsolókkal kerülhetjük el a csatlakozást. Előfordulhat például, 
hogy a cluster - amely ugye virtuális - valamilyen oknál fogva 
nem érhető el, ekkor az egyes node-ok nevét is megadhatjuk, 
így a csatlakozás sikeres lesz. Ha tudni szeretnénk, hogy ponto- 
san hogyan csatlakoztunk, elég ránézni az ablak címsorára: a 
clusternév(clusternév) azt jelzi, hogy a clustert magát céloztuk 
meg, a clusternév(nodenév) viszont azt, hogy az egyik állomá- 
son keresztül érjük el a fürtöt. A clusternév(.) azt jelzi, hogy az 
egyik állomásról LPC hívásokkal dolgozik a bedolgozó modul. 
Normális működés közben ennek nincs jelentősége, hiba esetén 
viszont nem árt tisztában lenni a kapcsolódás mikéntjével. 

A bedolgozómodul bal oldalán a clusternév szerepel a fa gyöke- 
reként. Ebből nyílnak az erőforráscsoportok, az összes erőforrás 
gyűjtőmappája, a cluster konfigurációs mappája, valamint a fürt 
állomásai. 


Ág Custer Administrator, - [AJK-CORPSERVJ , (4.JK-CORPSERV1]J, 
ÉJ Fle View Window Help -8x 


55] ola zer] Al elsz [mi 
f Name 























— Eg) AJK-CORPSERVI Tsae Tome Resource Type [Description 
Önine  AJKSERVERI — DHCP Servize 
nine AJKSERVERI  PhysicalDisk 
Önine  AJKSERVERI Physical Disk 
EJ Elsa (Home Önine — AXKSERVERI File Share 
j ez EJ ciustor Corfiguration. [ST Önáne  AJKSERVERI File Share 
ÉLÉT AMSARÍSAL gmsir Onine  AJKSERVERI File Share 
I s áj AJKSERVER2 ÜPRoFnes Önine — AJKSERVERI Fe Share 
I Spooler Onine  AJKSERVERI Print Spooler 
I MÜ SRV21P Address Onáne  AJKSERVERI IP Address 


9 A Cluster Administrator felülete 
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Az ablak jobb oldalán a mindenkori aktív konténer tartalmát lát- 
hatjuk, nagyon gyakran állapotinformációkkal fűszerezve. Ez 
fontos momentum. A rendszergazdai felület precízen és azonnal 
megjeleníti a cluster komponenseinek állapotát, ami alapján a 
teljes cluster állapotára következtethetünk. Nem sok ilyen álla- 
pot létezik, érdemes felsorolni őket: 

Online (működik) : A clustererőforrás létezik és működik. Ezt az 
állapotot szeretjük leginkább. 

Offline (nem működik): Az erőforrás nem üzemel. Ez nem biz- 
tos, hogy hiba. Az erőforrások meghatározott sorrendben vehet- 
nek fel állapotokat, valahogy úgy, ahogy azt az ábra mutatja. 


(online) (failed) (ontine) 
A aZ 
zt 


5 Az erőforrások lehetséges állapotai 


Látható, hogy az offline állapot korántsem csak hibát jelent, 
hanem egy átmenetet is az egyik online állapotból a másikba. 
Ez történik például akkor, amikor egy csoportot átmozgatunk 
egyik állomásról a másikra. 

Online pending (élesztés közben): Az előzőekből következően 
ez egy átmeneti állapot. Lehetséges azonban, hogy az erőforrás 
ebben az állapotban beragad, ami komoly hibára utalhat. 
Offline pending (lekapcsolás alatt): Az előző állapot tükörképe. 
Failed (sérült): Ez a tényleges hiba, a cluster nem képes elin- 
dítani a csoportot vagy erőforrást. Gyakorlatilag bármely állapo- 
tot követheti , sérült" állapot. A Cluster Administrator elég szi- 
gorú, és már akkor is ilyen állapotjelzővel ,címkézi" az erőfor- 
ráscsoportokat, ha egyetlen erőforrás nem online állapotban 
van. Ez ,ergonómiai hiba", ha lehet így fogalmazni. 


A cluster parancssori felülete 


A Cluster Administrator nem az egyetlen kezelőfelülete a fürtök- 
nek. Ha valamilyen oknál fogva nem áll rendelkezésre a grafikus 
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felület, de a parancssoros igen, a node system32 

könyvtárában megtalálható a cluster.exe program, 

amely a net parancshoz hasonlóan igen gazdag 
funkciókészletet nyújt, szinte mindent megtehetünk - 
ha éppen nem mindent. A szintaxisa roppant egyszerű: 


cluster [cluster név] /option 


vagy 
cluster [cluster név] node [node név] /option 


Így lehet például egy megosztáserőforrást létrehozni: 


X: 
MD TestShare 
cluster . res "TestShare" /create 


/group:"Groupl" /type:"File Share" 

cluster . res "TestShare" /priv 
path-"X:NTestShare" 

cluster . res "TestShare" /priv 
Sharename-TestShare 

cluster . res "TestShare" /priv Remark-"Teszt 
megosztas" 

cluster . res "TestShare" /prop Descriptionz"Teszt 
megosztás" 

cluster . res "TestShare" /priv 
securityzDomainílser grant ,c:security 

cluster . res "TestShare" /priv ShareSubbDirszl 

cluster . res "TestShare" /AddDep:"Disk X:" 

cluster . res "TestShare" /AddDep:"Network Name" 

cluster . res "TestShare" /On 


Nincs arra mód, hogy az opcióknak akár csak egy részét is ismer- 
tessük. A cluster.exe elsősorban akkor válik hasznossá, amikor egy 
rendszeresen ismétlődő feladatot kell végrehajtani, és ehhez szük- 
séges a cluster állapotának lekérdezése, esetleg megváltoztatása. 


A cluster beállításai 

Mielőtt az egyes mappák tartalmában részletesen elmerülünk, érde- 
mes megvizsgálni a cluster tulajdonságait. Kattintsunk a fa gyöke- 
rére a jobb oldali egérgombbal, majd a , Properties..." menüpontra. 
A telepítővarázsló kérdéseire adott válaszaink nagyobbik része 
itt található. A négy fülből igazából kettő izgalmas, a Ouorum 
és a Network Priority. 
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£JK-CORPSERVA, Properties. 


General. Auorum ] Network Ptiority ] Security ) 


sg AJK-CORPSERVI 


Cluster maintenance files — 


Auorum resource: 


0: (Duorum disk) sei 
MMSCST ! 


Partition: 


Root path: 


Reset guorum log at: 14096 KB 


Az alapérték csak 64K. 
Írjuk át 4096-ra! 








5 A cluster tulajdonságai 


Ha nem voltunk kellően megfontoltak, és új helyet kell találnunk 
a guorum adatbázisnak, azt itt tehetjük meg. Ezt azonban csak 
normál működés esetén lehet elvégezni. Egészen más a teendő, 
ha a guorum lemez megsérül, vagy az adatbázis megy tönkre. Lesz 
még hely és alkalom, hogy erről értekezzünk. A fülön van egy fon- 
tos paraméter, ez a guorum log mérete. Alapértelmezetten csupán 
64K. A 0225081 leírása szerint ez kevés lehet, ha nagyszámú 
megosztásunk vagy egyéb erőforrásunk van, érdemes tehát meg- 
növelni 4096K-ra. Ezt elég egyszer elvégezni és a clustert sem kell 
újraindítani a változások érvényre jutásához. 

A , Network Priority" panel pontosan arra való, amire a neve 
utal. A varázsló kérdésére adott válasz itt módosítható. Akkor 
fordulhat ez elő, ha utólag telepítünk egy második kártyát. Ez a 
fül azonban csak a már illesztett kártyák sorrendjét változtatja 
meg, a szerepüket nem. Ha ez utóbbit is állítanunk kell, akkor 
a ,Cluster configuration" konténer , Networks" mappájában kell 
megkeresnünk a hálózati csatolót, és módosítani a szerepét. 

A teljesség kedvéért említsük meg a biztonsági lapot is. A fej- 
lesztők nem vitték túlzásba a biztonsági beállítási lehetősége- 
ket. Egy fióknak vagy nincs jogosultsága a cluster kezeléséhez, 
vagy mindent megtehet. Úgy érzem, az a szemlélet érhető itt 
tetten, miszerint a virtuális szerverek mégsem igazi szerverek 
(még!) . Nem önálló egységek, amelyek külön felelőst igényelhet- 
nének, sokkal inkább a teljes fürt az, amely a felelősség határát 
meghúzza. Hogy ez a későbbiekben változni fog, az bizonyos. 

A fent tárgyalt párbeszéd-paneleket ritkán fogjuk használni, hi- 
szen nem naponta változik egy fürtözött konfiguráció. Annál in- 
kább a napi munka része a csoportok és erőforrások kezelése, 
lássuk tehát, mi mindent tehetünk. 


Csoportok 

Ha az előre létrehozott közös lemezeket a varázsló kérdésére 
mind a cluster kezelésébe utaltuk, akkor már az első induláskor 
több csoportunk is van, amelyek nemes egyszerűséggel a , Disk 
Group 1..n" nevet viselik. Az első csoport kivétel csak, ő a 
vCluster Group" Ez tartalmazza a cluster név, cluster IP cím és 
guorum erőforrásokat. Amikor munkahelyemen az első clustert 
üzembe helyezték, a szállítónk előre telepítette a clusterszolgál- 
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tatást az általunk megadott erőforrásokkal és virtuális kiszolgá- 
lókkal együtt. A csoportok neve megegyezett a virtuális szerve- 
rek nevével. Az első saját telepítésemig azt hittem, hogy a cso- 
portnév és a virtuális szervernév egy és ugyanaz, de ez nem így 
van. Érhető is: vannak olyan csoportok, amelyek nem virtuális 
kiszolgálók, tehát nincs NetBIOS, csak csoportnevük. Az utóla- 
gos beállítás azonban hasznos, hiszen nem kell folyton a cso- 
portnevek mellé rendelni a szerverneveket. Azt javaslom tehát, 
hogy minden csoportot, amely egyben virtuális kiszolgáló is, 
nevezzék át a rendszergazdák a virtuális szerver nevére, beleért- 
ve az első csoportot, vagyis a clustert is. Nem kötelező ez, csak 
egyszerűbbé teszi az életet. Az átnevezés nagyon egyszerű: 
jobbklikk a csoporton és , rename". 

Új csoport felvétele hasonlóan könnyű: jobbklikk a fa gyökerén: 
new -: group. A létrehozott csoport nem tartalmaz erőforrásokat, 
persze tetszés szerint feltölthető újakkal vagy már meglévőkkel. 
Ez úgy végezhető el, hogy offline módba kell tenni az erőforrást, 
majd jobbklikk: ,change group -s group name". Egy fontos dol- 
got azonban figyelembe kell venni, ez pedig a függőség. 


A függőségek 
A cikksorozat első részében már definiáltuk, hogy ez mit jelent, 
most az első erőforrások létrehozásánál a gyakorlatban is alkal- 
maznunk kell a korábban leírtakat. Nincs olyan KB cikk, amely 
minden egyes lehetséges erőforrást leír és meghatározza, hogy 
mely más erőforrásoktól függhet. Általánosságban a 0171791 
foglalkozik a kérdéssel. Néhány ökölszabályt érdemes megfogal- 
mazni, ezek könnyedén megvalósíthatók a gyakorlatban. 
1. A lemezerőforrások soha ne függjenek más erőforrásoktól. 
2. Nem függ más erőforrásoktól az IP cím és a Time service 
resource. 
3. A ,Network name" mindig az IP címtől függ. 
4. A fájlmegosztás a ,Network name"-től és a lemez erőforrástól 
függ. 
5. A fájl- vagy adatbázis műveleteket végző erőforrások mindig 
függnek a fizikai lemeztől. (PL.: WINS) 
6. A hálózati szolgáltatások mindig függnek az IP címtől, néha 
a hálózati névtől is. 
A szabályok nagyobbik része értelemszerű, magyarázatra sem szo- 
rul. Mindenképp érdemes egy kis időt szentelni a függőségekre, és 
akár kis téglalapokkal ábrázolni is lehet. Törekedni kell az egysze- 
rű, átlátható ábrára. Úgy kell kialakítani a hierarchiát, hogy egy 
erőforrástól ne függjön kétféleképp egy másik erőforrás. Például 
ha a fájlmegosztás már függ a hálózati névtől, akkor nem kell füg- 
gővé tenni az IP címtől, hiszen már a hálózati néven keresztül 
amúgy is függ tőle. Ez nem minden erőforrás esetén tartható. A 
WINS és DHCP erőforrások például követelik mind a hálózati név, 
mind az IP cím függőséget, nem is lehet definiálni őket másképp. 
A függőség a gyakorlatban úgy érvényesül, hogy egy erőforrás indí- 
tása csak akkor kezdődik el, ha már minden erőforrás, amelytől függ, 
sikeresen elindult. Minél több tehát a függőség, és minél hosszabb a 
függőségi sor, annál később indulnak el a sor végén álló erőforrások. 
A jelenlegi ismeretek alapján nem meglepő már, hogy az erőfor- 
rások függőségét csak azonos csoporton belül lehet létrehozni. 
A különböző csoportok ugyanis elkerülhetnek az azonos állo- 
másról, így a függőség érvényesítését nem lehetne garantálni. 
Végezetül ajánlom, hogy a triviális függőségek mellett tárjuk fel 
a logikai függőségeket is. Például egy clusterre fel nem készí- 
tett, de általános szolgáltatás-erőforrásként definiálható veze- 
tői információs rendszer függhet az SOL Servertől, amely az ada- 
tokat szolgáltatja neki, jóllehet ezt a függőséget semmi nem 
követeli meg, csak a rendszergazda ítélőképessége. 
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Át- és visszaköltözés, újraindulás (Egy 
Ha már a függőségeket megemésztettük, ismerked- [ol 


jünk meg az utolsó fontos fogalmakkal a gyakorlat- 

ban: az át- és visszaköltözéssel, valamint az újraindu- 

lással. Adódik az eset: egy erőforrás abnormális állapotba 
kerül. Mit tegyen ekkor a cluster? Egyáltalán hogyan értesül er- 
ről? Elég fontos kérdések ezek, tulajdonképpen a rendszer szí- 
ve-gyökere ez a funkció. Mi másért tartanánk egy clustert, ha 
nem azért, hogy éppen ezt tudja. 

A cluster szerviz egyik igen fontos feladata az erőforrások álla- 
potának figyelése, valamint annak ellenőrzése, hogy az erőfor- 
rás valóban ellátja-e a feladatát. A kétféle ellenőrzést , Looks 
alive"-nak (, úgy tűnik, él") és ,Is alive"-nak (, valóban él") ne- 
vezhetnénk el az erőforrás tulajdonságlapja alapján. Az első 
esetben az ellenőrzés abból áll, hogy a szolgáltatás megnézi a 
regisztrációs adatbázis cluster részét, vajon minden rendben 
van-e. Kiindulásnak nem rossz ez az ellenőrzés, mert az erőfor- 
rást nem terheli, elég egyszerű és gyors, csak az a bökkenője, 
hogy mindig a saját korábbi vizsgálatára támaszkodik, tehát 
nem igazi ellenőrzés. Ezzel a vizsgálattal valóban csak azt lehet 
mondani: ,Úgy tűnik, hogy működik." Ez az ellenőrzés sokáig 
nem folytatható, ezért néha meg kell vizsgálni azt a futó prog- 
ramszálat (program thread) , amely az erőforrás maga. Ez az ,is 
alive" vizsgálat. Ez már igazi ellenőrzés, cserébe egy icipicit 
foglalja és fogja a rendszert. Ez már csak így szokott lenni. 
Nos, tegyük fel, hogy egy ilyen ,is alive" vizsgálat során azt tapasz- 
talja a cluster szolgáltatás, hogy nem válaszol a programszál. Ekkor 
válik igazán fontossá, hogy az erőforrás és a csoport, amelyben az 
erőforrás székel, milyen átköltözési szabályokkal rendelkezik. 


Disk U: Properties 


General ] Dependencies Advanced ] Parameters ) 


Disk U: 


€ Donotrestart 
(7 Restart 
! [7 Affect the group 


Threshold: [8 Period: 300 seconds / 


r "Looks Alive" poll intervak —— "s Alive" poll intervalk 
! C Use value from resource type / ! € Use value from resource type / 
(s Specify value: IÍG Specify value: ] 


5000 milliseconds 60000 milliseconds ! 
új snszzil ! 


seconds 


Pending timeout: 1180 








5 Átköltözési szabályok egy erőforrásnál 


A panel alapján akár azt is megtehetjük, hogy hiba esetén nem 
teszünk, illetve a rendszerrel nem végeztetünk semmit. (,, Do not 
restart"), bár még nem sikerült igazán olyan életszerű szituáció- 
val találkoznom, ahol ez lett volna a helyes választás. Szinte bi- 
zonyos, hogy legalábbis újraindítjuk az erőforrásunkat. Meg kell 
adnunk viszont, hogy az erőforrás állapota hatással legyen-e a 
csoport állapotára (,Affect group"). Ha azt választjuk, hogy 
nem, akkor a helyreállítási procedúra a következőkből áll: 
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1. Ha még nem fagytak le, akkor a clusterszolgáltatás 
leállítja a hibás erőforrástól közvetve vagy köz- 
vetlenül függő erőforrásokat. 

2. A ,Period" (, időköz") mezőben megadott másod- 
percen belül maximum a ,threshold" (, próbakü- 
szöb") mezőben meghatározott alkalommal meg- 
próbálja újraindítani az erőforrást. 

3. Ha sikerül az újraindulás, akkor a függő erőforrásokat is meg- 

próbálja elindítani. 

4. Ha nem sikerült a start, akkor az erőforrás és minden tőle füg- 

gő más erőforrás is , Failed" (, Hibás") állapotban marad. 

5. Megvizsgálja, hogy a függő erőforrások hibás állapota érinti-e 

a csoportot. Ha nem, akkor a helyreállítási procedúra leáll. 

A legfőbb fegyvert, az átköltözést ilyenkor nem használjuk. A 
költözés ugyanis a csoport joga, mi viszont nem kívántuk esz- 
kalálni a problémát csoportszintig. Jó ez így? Hiszen nem tud- 
hatjuk, hogy mi a hiba oka, s talán ,máskor, más helyen" (értsd: 
a másik állomáson) működhetne a szolgáltatásunk. Bármilyen 
fura, lehetséges, hogy ez jó megoldás. Tegyük fel, hogy több 
száz megosztást definiáltunk clustererőforrásként. Ha egy 
könyvtárat véletlenül törlünk, a hozzá tartozó erőforráscsoport- 
nak sokáig tartana átköltözni a másik állomásra, ráadásul feles- 
leges lenne az átköltözés, hiszen a többi erőforrásnál ez csak 
kiesés, míg a törölt könyvtárnak úgyis mindegy, ha egyszer tö- 
rölni akartuk. Fontoljuk meg tehát, hogy érintse-e az erőforrás 
összeomlása a csoportot. Ez néha szükséges, néha nem - egyér- 
telmű tanácsot csak konkrét környezetben lehet adni. 

Bevallom, hogy az előbb kicsit csaltam. Hiszen az 5. pontban az 

is előfordulhatott volna, hogy a függő erőforrás már érinti a 

csoport átköltözését. Igen, ekkor valóban megkezdődik az át- 

költözés. Ha ezt szeretnénk elkerülni, akkor át kell nézni min- 
den, az erőforrástól függő más erőforrást és a megfelelő jelölő- 
négyzetben eltüntetni a kis pipát. 

Ha az erőforrás magával rántja a csoportját, akkor megindul az 

átköltözés a... hova is pontosan? Nos, az erőforrás által kijelölt 

másik állomásra. (Tulajdonságok panel, ,,Possible owner" bejegy- 
zés) Advanced Server esetén ez kissé nagyzolásnak tűnik, hisz 
már csak egy szerverünk maradt, ahová a csoport átgördülhet, 

Datacenter Servernél viszont három vagy négy állomás is alkot- 

hat clustert, turkálni lehet a választékban. Ám ennek az ellenke- 

zője is előfordulhat, hogy nincs is másik szerverünk. Miért? Le- 
hetséges, hogy nincs is második állomás? Igen, lehet. A cluster 
állhat akár egy node-ból is, ekkor nem lehetséges az átköltözés. 

Akkor fordul ilyesmi elő, ha a cluster első állomását előbb állít- 

juk üzembe, mint a másodikat, de gondolva a jövőre, már az el- 

ső node-on úgy állítunk be mindent, mintha teljes kiszolgálófür- 
tünk lenne. Az új gép csatlakozásakor a cluster szerencsére el- 
végzi nekünk, hogy minden erőforrásunknak legyen lehetséges 
tulajdonosa az új állomás is, ennek ellenére fontos a következő 
szabály: egy csoportban minden erőforrásnak legyenek ugyana- 
zok a node-ok, ugyanolyan sorrendben preferált szerverei! Ez 
nem zárja ki, hogy egy csoportnak továbbra is csak egy preferált 
állomása legyen. Lehet, hogy egy szoftvert (pl. Exchange) ugyan 
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clusterre telepítettük, clustererőforrásokként működnek a szol- 
gáltatásai, de nem rendelkezünk egy második kiszolgálólicenccel 
ahhoz, hogy a második node-ra is felrakhassuk szegényt. Ekkor 
bizony be kell állítanunk, hogy minden Exchange erőforrásnak, 
sőt az egész csoportnak csak egyetlen állomás legyen a birtoko- 
sa. Hiba esetén újraindítás lehetséges, átköltözés nem. 

Mi történik akkor, ha a csoport nem tud elindulni azon az állomá- 
son, amelyre át szándékozott költözni és megpróbál azonnal vissza- 
költözni az első állomásra? Az örökciklust azért kivédték a tervezők. 
A csoport tulajdonságai között is megadhatók átköltözési szabá- 
lyok. Jobbklikk: ,A csoport neve" -: Properties -- Failover. 

A threshold érték szabályozza, hogy hányszor indulhat újra má- 
sik állomáson egy csoport egy átköltözési periódusban. Ezután 
a cluster szerviz offline állapotba teszi a csoportot. A periódus 
hosszát a Period érték adja meg. Vagyis: ha 11-szer indulna új- 
ra a csoport, de a küszöbérték 10, akkor a cluster kikapcsolja a 
csoportot, amíg le nem jár az átköltözési periódus. A cluster 
szerviz újraindításával új periódust lehet kezdeni. 


4JK-CORPSERYV2 Properties 





General Failover ] Failback ] 


cí AJK-CORPSERV2 


6 hours 


Threshold: 


Period: 
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És a visszaköltözés? Alapvetően két lehetőségünk van: a kiszolgá- 
lókra bízzuk, vagy magunk végezzük el. Ha magunk végezzük el, 
az biztonságos és a megfelelő időben történik, csak kényelmet- 
len. Egyrészt kézzel kell megoldani, fejben kell tartani a felada- 
tot, másrészt a visszaköltöztetést szinte bizonyosan egy kevésbé 
frekventált időben, este vagy éjszaka kell végrehajtani, ezt pedig 
senki sem szereti. Elvégzi a visszaköltöztetést a cluster is, még- 
hozzá pontosan úgy, ahogy azt mi szeretnénk. Választhatjuk azt, 
hogy a csoport regenerálódás után azonnal röppenjen vissza a he- 
lyére, de megadhatjuk azt is, hogy ez a mozgás egy adott nap- 
szakban történjék meg. Mérlegelni itt azt kell, hogy az üzemelte- 
tési paraméterek (pl. válaszidő) elsőbbséget élvez-e a rövid 
kieséssel szemben, amelyet a napközbeni visszaállás okoz. 


Most már minden tudásunk megvan, hogy erőforráscsoportokat 
és erőforrásokat hozzunk létre. A következő alkalommal a fájl- 
és nyomtatóerőforrásokkal kezdünk. 


Lepenye Tamás, MCSE 2000 
lepenyet oimal.hu 


SÜNE "05 s 


Ki mivel 


v? 


Farkasokkal Netmonozó 


Emlékeznek még a ... típusú nyomtató esetére, mely beállt a fürtbe? 
Azt a cikket Lepenye Tamás követte el, a NetMon sorozatba , furakodva". Most 
pedig én fogok az ő szakterületébe belekotyogni egy fürtküzdelem kapcsán. 


Adva van egy cég, korlátlan pénzügyi lehetőségekkel. Igen, egy 
bank. Megveszik a világ egyik legdrágább clustervasát, mivel nekik X 
kilences rendelkezésre állás kell. Megy is a fürt szépen - egy darabig. 
Egyszer csak telefonhívásra lesznek figyelmesek a rendszergaz- 
dák: a mission critical alkalmazás nem elérhető a fürtön. Mi a 
hibaüzenet? A szolgáltatás megtagadva, mert a tartományve- 
zérlő nem válaszol az autentikációs kérésekre. Hmmm. Létrejött 
égy Achilles sarok a fürtön kívül? A single-point-of-falilure 
(SPOF), melyre nem gondoltunk? Néhány gyors ellenteszt (kije- 
lentkezés, bejelentkezés, MSSOLServer stop-start stb.) alapján ki- 
derítik, hogy a tartományvezérlők igenis válaszolnak. SPOF- 
helyzet amúgy sem lehet, hisz nem egy darab tartományvezérlő 
van, hanem öt. Mire idáig jutnak a nyomozásban, a hiba magá- 
tól megszűnik, az alkalmazás szépen fogadja a munkaállomások 
kéréseit. Múló rosszullét csupán? 

A második felvonásra több napot várni kell. De eljön. A legádázabb 
munkaidő kellős közepén a fürtalkalmazás ismét kirugdalja a júz- 
ereket. A hiba oka ugyanaz: ,No DC has answered for the authen- 
tication reguest." Számítva arra a lehetőségre, hogy a hiba eset- 
leg ismét hamar elmúlik, az előző teszteket nem hajtják végre 
(azaz nem vacakolnak a DC-k válaszainak tesztelésével, mert úgyis 
tudják, hogy válaszolnak, hisz a fürtön kívül senki nem panaszko- 
dik), hanem futás a clusterhez, NetMon indít. Mit látnak? A mis- 
sion critical app. folyamatosan kapja a bejelentkezési kéréseket, 
és azonmód továbbítja az egyik DC-nek. A NetMon trace tartalma: 
b WINS lekérdezés, 1C (tartományvezérlő) rekordokért 

8 WINS válasz, benne mind az öt DC 

"2 Netlogon SAM Logon Reguest mind az ötnek 

"2 amire nem jön válasz egyiktől sem 

Ejnye no, mi a csuda van itt? Passz. Elmentik a trace fájlt, hátha 
jól jön még. Megpróbálják ugyanezt megnézni a DC oldaláról. 
Futás, futás, mert megjavul! És valóban, mire odaérnek, a fürt 
kikeveredik a slamasztikából, és minden megy tovább. Ha már a 
NetMon kicsúszott a kezük közül, legalább körülnéznek az omi- 
nózus DC-n. Az Event Viewer tanúsága szerint semmi nem tör- 
tént. Nincs mit tenni, várniuk kell a következő botlásig. Nagyon 
ciki az ügy, a tízmilliós fürt botladozik. Hol háromóránként, hol 
kétnaponta, hol egy percre, hol ötre kiakad. Mi az, hogy az X 
kilences méregdrága rendszer megbízhatatlanabb, mint a sarki 
fűszeres PC-je? Munkakönyvszag terjeng a levegőben. Elhatáro- 
zás születik külső szakértő bevonásáról. 


A vadászat 

A Nagy Hibavadászatra ezúttal meghívtak engem is. Első dolgom 
az Event Logok áttanulmányozása. Semmi különös nincs bennük, 
csupa info ikon. A fürt köszöni jól van, a heartbeat ismét dobog 
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stb. Két nap üldögélés után a fürt hálIstennek megint megborul. 
Nem is baj, mert olyan eszméletlen hideg volt a szerverszobában, 
hogy a fogunk csattogása elnyomta a gépek búgását. Végre egy 
kis mozgás, lehet rohanni. Nosza, futás a DC-khez, NetMont elő, 
hálózati forgalmat elkapni! És lett nagy csodálkozás. Mert az 
összes DC válaszol, de valami miatt nem kapja meg a fürt! Pedig 
tisztán látszik: ugyarra a MAC Addressre megy a válasz, ahonnan 
a kérdés jött. Hova tűnik? Talán rossz a fürt egyik csomópontjá- 
nak kártyája? Ennek ellentmond, hogy minden más hálózati for- 
galmat megkap. Sőt, a DC nézőpontjából figyelve az eseménye- 
ket, a Netlogon SAM Logon Response-t is megkapja. Hmmm. 
Agyak őrült zakatolása hallik, míg végre valaki megszólal: 

Az nem a fürt, hanem a router MAC Addresse!" 

Lám, mi mindenre jó egy olyan kolléga, aki fejből tudja a vállalat 
összes gépének MAC Addressét! Tényleg! Hisz a DC meg a fürt két 
külön alhálózaton van! A router a bűnös, eldobálja a válaszcsoma- 
gokat. De hát miért? Mivel ezt nehéz lenne tőle megkérdezni, fag- 
gasuk tovább az imént elkapott hálózati forgalmat, hátha ki lehet 
sütni belőle valamit! Kettőt kattintok az egyik csomagon. Első rá- 
nézésre semmi különös. De ismét bekiabál az iménti kolléga: 

Az nem a fürt IP címe! Az valami szemét!" 

Na igen. Ennyit tesz a helyismeret. Jókora lépéssel közelebb ke- 
rültünk a probléma gyökeréhez: úgy tűnik, mintha a Logon 
Reguestet nem is a fürt küldené, ergo a válasz sem hozzá megy 
vissza. Hamisított IP cím egy banki hálózaton? Hackert fogtunk? 
De jó lenne! Lehetne hívni a sajtót! Hírnév, siker, pénz, csillogás! 
Most kisebb nyomozás következik, hogy megállapítsuk, honnan 
jön a szemét. Most már sehonnan, mert közben ismét meggyó- 
gyult a hálózat. A szemét IP cím elvileg senkié, ilyet a DHCP 
Server sem ad ki. Azonban beletekintve a legelőször lementett 
fájlba (mely a fürtön készült) kiderül, hogy a Netlogon SAM Logon 
eleve szemét IP címmel kerül ki a netre. Ha figyelmesebbek let- 
tek volna, majdnem egy hetet megspórolhattak volna! Innen már 
csak néhány kattintás, és megvan a döbbenetes eredmény: a sze- 
mét nem más, mint a fürttagok magánhálózatán (heartbeat net- 
work) , a crossover kábelen használt IP cím, amit teljesen jogo- 
san állított be a telepítőszemélyzet akármire, mert az a cím soha 
nem kerül ki a publikus hálózatra. Kivéve, ha mégis. Egy-két kat- 
tintás, és kiderül a ,hiba" oka: valaki átállította a heartbeat há- 
lózatot úgy, hogy ,both" legyen, azaz mind heartbeat, mind ügy- 
félforgalom céljára igénybe vegye a fürt. Jó kérdés, hogy miért 
zavarodott bele a node, és adott fel az egyik kártyán olyan cso- 
magokat, amelyek a másik kártya IP címét viselték, de talán még 
izgalmasabb az, hogy ki a fene állította át? Ki volt az a pancser? 
Hát ezt majd a banki dolgozók lerendezik maguk közt, én 
visszaállítom normálisan private hálónak, veszem a kalapom és 
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megyek. Pár nap alatt kiderül, hogy egyedül két em- 
, . bernek volt joga ilyesmihez, de mind a kettő tagad. 
Mit bánom én, fő a sikerdíj! 


A negyedik felvonás körülbelül egy hét múlva követke- 

zett, amikor már senki nem számított rá. A heartbeat hálóza- 
tot valaki megint átállította publikusra. Ezalkalommal gyorsan 
cselekedtek, és visszaállították a heartbeatet privátra. Hurrá. 
Három hét telik el békében. A fürt dolgozik. Egyszercsak megint 
közlik, hogy átállította valaki. De ki tette? Mégiscsak hacker 
van? A két jogosult személy tagad, sőt alibit is felmutat: azon 
a héten végig tanfolyamon voltak. Tekintettel a ,bűntény" tö- 
kéletesen értelmetlen voltára gyanakodni kezdtem, hogy talán 
magától áll át időnként. Vajon miért? 
Dr. Watson a helyszínen összeszedi a legkisebb nyomokat is. 
Csikkek, lábnyomok, Event Logok kerülnek a nylonzacskókba. 
Lássuk, hátha valami mégiscsak megbújik itt? A fürt logjában 
mint korábban említettem, csupa semmi áll. A heartbeat ismét 
a privát hálózaton fut. Mi az, hogy ismét? Gyűjtsük csak ki eze- 
ket az eseményeket! Három ilyen van, ebből az utolsó kettő - 
pont a behülyülés napjára esik. Vajon a harmadik is? Elküldtem 
ímélben a három dátumot a bankosoknak, mondják meg mi jut 
róluk az eszükbe. Jön a válasz: ezeken a napokon állítódott át 
a fürt. Nyomon vagyunk! Hopp, mégegy válaszlevél beesik, az 
utolsó utáni, képesítés nelküli rendszergazdától: ezeken a napo- 
kon szerelték a klímát. Nocsak-nocsak! Mégis egy Achilles sarok, 
egy SPOF áll a háttérben? De mi köze lehet a klímához? A fürt 
jól bírta a klimatizáló berendezés hiányát, de a kijavítást nem! 
Klimaszerelészfürtbehülyülés. Vajon miért? 


A probléma első része: hardverhiba 

Nem csigázom tovább Önöket, elárulom a titkot. A heartbeat 
hálózat egyszerű, házi berhelésű keresztkábellel (crossover) volt 
kialakítva. Íme a SPOF. A kábel ugyanis kontakthibás volt, ami 
mindig akkor jelentkezett, amikor valaki elsétált a cluster 
MÖGÖTT! Ki járkál a gépek mögött? Még a takarítószemélyzet 
sem. De bizony a klímaszerelők igen! Megbökik a kábelt, a 
heartbeat elhal, a fürt pedig - okosan - átáll a publikus háló- 
zat használatára. Amint a kábel visszatér eredeti helyzetébe, az 
Eventlogban megjelenik a bejegyzés: a heartbeat ismét a privát 
hálózaton fut. Már csak az a kérdés, hogy ennek miköze a heart- 
beat IP címek külső hálózaton észlelt felbukkanásához? 


A probléma második része: Media Sense 

A Windows NT 4.0 Enterprise Edition fürtje óriási hiányossággal 
rendelkezett: nem vette észre, ha a publikus hálózati kapcsolat 
veszett el. Egyszerűen nem következett be ilyen esetekben 
failover, mert a fürt jól van. Ennek a hiányosságnak az az oka, 
hogy az NT4 maga képtelen detektálni a hálózati kapcsolat meg- 
szakadását. Nem úgy a Windows 2000! Ha kitépjük a kábelt az 
Ethernet kártyából, azonnal jelzi, hogy oda a kapcsolat. Erre a 
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fíicsörre a fürt is épít, és ha a felhasználói hálózattal megszakad 
a kapcsolat, költözik a hivatal. Ám a Media Sense eléggé furcsán 
működik. Megpróbálta már valamelyikük megállapítani a gép IP 
címét, ha nincs bedugva a hálókábel? NT4 esetén ilyenkor is 
volt IP cím. A Windows 2000 azonban ezt mondja: 











Command Prompt 


icrosoft Windows 2000 (Version 5.00.2195] 
(C) Copyright 1985-2000 Microsoft Corp. 





:"Vipconfig 
indows 2000 IP Configuration 
thernet adapter Local Area Connection: 
Media State . . . . . . . . . . . : Cable Disconnected 
:V 


5 Windows 2000: Ha nincs hálózat, akkor nincs IP cím sem! 


Nem is lenne ezzel semi baj, ha csak az IP cím tűnne el. De saj- 
nos kiszalad a memóriából az egész pereputty, kártyameghajtós- 
tól, mindenestül, méghozzá mindkét Node-on. On-demand Plug- 
and-Play. Úgy eltűnik, mintha sosem lett volna. Eltűnik a 
Cluster fennhatósága alól is. 

S amikor visszadugjuk a kábelt? Új kártya születik! Ráadásul 
mindkét Node-on. Nincs mihez párosítani. Ha csak az egyik Node- 
on tűnt volna el, az IP cím alapján visszakerült volna a helyére. 
De a crossover kábel miatt mindkét Node elveszítette. Na ez a baj. 
Menet közben beszületik a fürt alá egy új kártya. Vajon mit te- 
gyen a fürt? Publikus, vagy heartbeat hálónak vegye fel? Tanács- 
talanságában both, azaz mindkét szerepre állítja be. S ezzel a tör- 
ténetnek majdnem vége. Hátra van még a végső megoldás. 


A Megoldás 

A megoldás egy Knowledge Base cikkben bujkál (0254651). 
Crossover kábel használata esetén tiltsuk le a Media Sense , szol- 
gáltatást". Vagy ne használjunk házi kábelt. Vagy ne crossovert. 
A figyelmes olvasók talán észrevették: ezt a beállítást Lepenye 
Tamás a decemberi Farkasokkal már megírta. Neki van igaza. Aki 
fürtöt használ, legyen tudatában annak, mit tesz. Legyen 
óberokos, olvassa át az összes vonatkozó információt. Az összes 
Knowledge Base cikk szabad szövegesen kereshető formában 
megtalálható az [1] címen. 


Szívműtéthez (heartbeat) ne a csontkovács szerszámait használjuk. 
Ennyit erről. 


Fóti Marcell 
marcellf onetacademia.net 


A cikkben szereplő URL-ek: 


[11 http://support.microsoft.com 
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A mai alkalommal a RIS kiszolgáló beállításait nézzük végig. A RIS összes 
felügyeleti szerve be van építve az Active Directory Users and 

Computers MMC snap-inbe, így ezzel a megszokott eszközzel (szinte) 
minden RIS-karbantartási feladatot elvégezhetünk. 


A RIS kiszolgáló beállításai 

Amikor a RIS kiszolgálóobjektumának tulajdonságait előhúzzuk 
(AD Users and Computers konzolon a kiszolgáló objektumán jobb 
klikk - properties), ott a következő kép fogad minket. 






CIZNZTTT TENKES TET] 
! 

General ] Operating System ] Member Of ] Location 1] 
ManagedBy — ] — Obiect  ] 0 Security Remote Install ! 


Aa You can manage this remote installation server and control the 
x eb way it interacts with existing and potential client computers. 


Client support 


vi el 
IT Do not respond to unknown client computers 








Check server 


If this remote installation server is exhibiting problems, select the "Verify 
Server" option to perform an integrity check. If problems are 
encountered they will be fixed. 


This option is only available from the server console. 


Verily Server I 








Show Clients... Advanced Settings... 





5 Remote Install tulajdonságok 


Client support - itt lehet be és kikapcsolni a RIS kiszolgálást. A 
fenti képen látható beállítás minden ügyfélnek válaszolni fog, aki 
hozzá eljut, míg ha bekapcsoljuk a második jelölőnégyzet is, ak- 
kor csak azoknak fog válaszolni, akiknek van már megfelelően elő- 
készített számítógépazonosítója a tartományban. Értelemszerűen, 
ha egyik pipa sincs a helyén, akkor a RIS kiszolgálót kikapcsoltuk. 
Verify Server - ellenőrizhetjük vele, hogy minden rendben van-e 
a kiszolgálóval - nem tesz mást, mint a risetup.exe-t indítja 
-check kapcsolóval, és csak akkor elérhető ez, ha az AD Users 
and Computers snap-int magán a kiszolgálón futtatjuk. 

Show Clients - megmutatja azokat az ügyfeleket, akiket az adott RIS 
kiszolgálóról telepítettünk. Egyszerű keresés az Active Directory-ban. 
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CATTTETESS ZETT g 
Ede Edt View Heb 


Findt [Remote installation Cbents 7] in [Ed Entre Directory e] Browse. 


Remote installation Ckentr [Advanced] 


GUID: Me 




















Riserverz [dícAr 
Name [ao 
No items match the current search 
JARAT EK E s át. át 





5 RIS ügyfelek felkutatása a tartományban 


Advanced Settings - itt tulajdonképpen az ügyfélszámítógépek 
elnevezését szabályozhatjuk, valamint a telepítőkészletek hoz- 
záadása/eltávolítása is innen lehetséges. 


fd ed 


[dett utas ue [En eet sea 7 0 





New Clients 1images] Tools ] Obiect] Security ] 


A 3 — Select a computer naming format for new client computers, and 
xz ab set the location in the directory service where client computer 
accounts will be created. 


r Client computer naming format: 
Generate client computer names using: 


semame EE 


Example: John Smithis computer would be named: 
JOHNSMI12 











(7 Client account location 


Create the client computer account in the following directory service 
location: 


(6 Default directory service location 
C Same location as that of the user setting up the client computer 


C Thefollowing directory service location: 
" Browse. j [ 
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5 Az ügyfélszámítógépek 
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E Nézzük meg közelebbről először az ügyfelek elnevezé- 


alJ 


seit. Itt tudjuk megmondani, hogy mi is legyen az Au- 

tomatikus telepítéskor létrehozott gépnév az Active 

Directory-ban. Választhatjuk a telepítést végző felhaszná- 

ló nevét, vagy a vezetéknév és a keresztnév kombinációit, vagy 
NP plusz a gép MAC címe, de választhatunk egyedi elnevezést is. 
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Using the following variables, you can create a format for automatically generating custom 
comouter names for new installations: 


Users first name: o Füst 
Users last name: Last 
Users logon name: 7Jsemame 
Ethernet MAC address of computers network adapter: MAC 
Incremental number: zt 

n characters of the indicated field: XrField 


(example: záFirst z first 4 characters of the users first name) 
Type the custom naming format you want to use: 


Format [aza 


Sample: The name generated for John Smith (username: JOHNSMI) is: 





nitúra telepítőkészlethez. Ebben a menüben adhatunk hozzá vá- 
laszfájlokat (Add gomb) a meglevő állományokhoz. 


New Answer File or Installation Image 
"You can associate a new answer file with an existing image, or you can add a new 
image. 








Doyou want to associate a new unattended Setup answer file to an existing installation image, 
or add an entirely new image? 


an 

tended answer file to an existing image. You can copy 
existing remote installation server, choose an existing sample answer 
File, or specily the path to an answer file. 


C Add anew installation image 
This option copies the contents of a Windovis 2000 Professional CD and associates a 


standard unaltended Setup answer file with the image. This option is only available at the 
server console. 








Back Next; 


Cancel 
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a Ügyfélszámítógépek neveinek testreszabása 


Ilyenkor mi magunk rakhatjuk össze az elnevezési konvenciót, 
majdnem ahogy tetszik. Nézzük a képen is látható példát: min- 
den gép neve W2K-val fog kezdődni, majd jön egy növekvő 
szám, a mi esetünkben max. 4 számjegyű lehet. Itt mindig a kö- 
vetkező legkisebb még használaton kívüli számot fogja felaján- 
lani az Ügyféltelepítő Varázsló. Ezen a néven fogja létrehozni a 
gépazonosítót a tartományban. Ha nem adunk meg számot, ak- 
kor alapértelmezés szerint 2 számjegy kerülhet a végére. 


Izgalmasabb az Images fül itt a beállítások közt. 








BIGA-Remote-Installation-Services PrODEFEESI 211 
New Clents . Images ] Todis ] Obiect]) Security] 

32 The following installation images are installed on this remote 

z ap installation server, 
Description Platform Language 
Windows 2000 Professional 1386 English 
Windows 2000 Professional - Office 2000 St... 1386 English 
a 2] 





Remove 


Properties Refresh I 








OK I Cancel ] épply I 


Itt láthatjuk az összes telepítőkészletet, amelyek az adott RIS 
kiszolgálón megtalálhatóak. Egy telepítőkészlet két részből áll: 
vannak a telepítéshez szükséges állományok a Remoteln- 
stallySetup WoLanguage9o Wmages vcimage dire könyvtárban, 
és van a felügyelet nélküli telepítéshez használt válaszfájl - SIF 
fájl. Több SIF fájlt is rendelhetünk ugyanazokhoz a telepítendő 
állományokhoz, de egy SIF fájl mindenképp szükséges egy gar- 
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5 Telepítőkészlet varázsló 


Ha egy teljesen új telepítőkészletet akarunk létrehozni, (mondjuk 
több nyelvi verzióra is szükségünk van), akkor válasszuk az Add a 
new installation Image varázslót. Ilyenkor bekéri a Windows 2000 
telepítő CD-t, fel fogja másolni annak tartalmát a megadott könyv- 
tárba, és egy alapértelmezett válaszfájlt is hozzá fog rendelni. 
Ha azonos a nyelvi verzió, de szükségünk van eltérő beállításokra a 
telepítéseknél, akkor nincs más dolgunk, mint egy előre létrehozott 
SIF fájlt összekötünk a már fentlevő telepítő állományokkal. Legegy- 
szerűbb az alapértelmezés szerint bepakolt SIF fájlt szerkeszteni. A 
következő részben lesz róla szó hogy mit lehet és kell tenni a 
válaszfájllal annak érdekében, hogy az valóban jól működjön. 
Ezek a válaszfájlok a RemotelnstallySetup WoLanguage"9o) Images) 
simagedir: V386itemplates könyvtárban tárolódnak. Amikor letör- 
lünk egy telepítőkészletet (Remove gomb) tulajdonképpen csak a 
SIF fájlt töröljük, a mögötte levő X Mb-ot nekünk kell letörölni kü- 
lön, az Explorer segítségével. 
Azonos nyelvi és service pack verzióból nem tehetünk fel több 
készletet, de lássuk be, erre nincs is semmi szükség. 
Viszont egyszerűen elérhetjük, hogy rögtön a Service Packkal el- 
látott telepítő állományokat használjuk az ügyfelek telepítésé- 
nél. Lássuk hogyan: 
8 Fel kell másolnunk a Windows 2000 Professional telepítő CD tel- 
jes tartalmát egy könyvtárba a merevlemezre. Legyen ez 
mondjuk d:(win2ksp2.pro könyvtár. 
Ezek után fogjuk a Service Packot, azt is bontsuk ki /x kap- 
csolóval. 
"0 Majd az i386Wpdate könyvtárából futtassuk a következőt: 
update -s:cdirz - annak könyvtárnak a nevét és teljes 


-h 


benne az 1386 könyvtárat! Tehát az előbbi példánál marad- 

va a parancs így fog kinézni: update -s:d:(win2ksp2.pro. 
"5 Mindezek után hozzáadhatjuk az így előkészített telepítőállo- 
mányokat az Add new installation image varázslóval, vagy a 
risetup.exe elindításával. 
Utolsó lépésként az eddig is használt válaszfájlt hozzárendel- 
jük a telepítőállományokhoz, és máris kész van a friss, ro- 
pogós telepítőkészlet. 


Az ügyfélgépek előkészítése 

Biztonsági szempontból mindenképp megfontolandó, hogy a 
RIS-es ügyfélgépeknek jó előre létrehozunk azonosítót a tarto- 
mányban. Ezt hívjuk pre-stagingnek. Miért is jó ez? Nos, a fel- 
használó még véletlenül sem fogja tudni elindítani a telepítést, 
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illetve nem kell a felhasználóknak extra jogokat osztani az 
Active Directoryban ahhoz, hogy telepíteni tudják a saját gé- 
peiket, ha a rendszergazda előkészíti a gépaccountot is. 

A cikk legelején már láttuk, hogy a RIS kiszolgáló gép account- 
jának Remote Install tulajdonságai közt találhatjuk mindjárt azt 
a beállítást, hogy a RIS kiszolgáló mely ügyfeleknek válaszoljon. 
A lenti kép beállítása azt mutatja, hogy a RIS kiszolgáló be van 
kapcsolva, tehát válaszolni fog az ügyfelek kéréseire válogatás 
nélkül. Ha a második négyzetben is ott figyelne a pipa, akkor csak 
azoknak az ügyfeleknek válaszolna, a melyeket már előkészítet- 
tünk. Ezt két okból lehet hasznos bekapcsolni. Ha a hálózaton van 
más olyan ügyfél, amely PXE-t használ, de nem RIS-sel akarunk rá 
telepíteni dolgokat, akkor ezeknek az ügyfeleknek a RIS kiszolgá- 
ló nem fog válaszolni. Másik ok pedig, hogy senki nem fog tudni 
kalóz módon felhúzni egy gépet RIS-sel, ha az nincs előkészítve az 
Active Directoryban, ugyanakkor mi sem fogunk tudni felvenni 
újakat csak akkor, ha valamilyen módon tudjuk a gép GUID-ját, és 
nem kell hozzá elindítani az ügyféltelepítő varázslót. 





Client support 
[Be 





TT Do not respond to unknown client computers 








SE rNTZENNSSÉRÉT 


0 A RIS kiszolgáló ki/be kapcsolása 


Ahhoz, hogy accountot tudjunk létrehozni az ügyfélgépnek a 
RIS telepítéshez, tudnunk kell annak egyedi azonosítóját, a 
GUID-ot. Ezt BIOS-ból meg lehet tudni, vagy ha elindítjuk az 
ügyféltelepítő varázslót az F12-vel, akkor miután beléptünk, ki 
fogja irni a gép nevét (amit generált neki a kiszolgáló) , a GUID- 
ot, és a RIS kiszolgáló nevét. Ezen a ponton le kell kapcsolni az 
ügyfélgépet, elég megjegyezni a gép nevét, majd ezt az ügy- 
félaccount-ot lehet manipulálni annak érdekében, hogy a meg- 
felelő névhez a megfelelő GUID tartozzon. 

A GUID egy csúnya 32-bites azonosító, amely a hálózati kártyához kö- 
tött. A PXE-t ismerő ügyfeleknél a GUID általában valahogy így néz ki: 


( 1f9885641-3045L-780a-123b-10524588721213) 

Amikor RIS indítólemezt használunk, ott a GUID nem más, mint 
az adott ügyfél hálózati kártyájának címe (MAC címe, rengeteg 
0-val az elején, hogy kijöjjön a 32 bit): 


(.20000000-0000-0000-0000-0050558FO2102) 


Miután megtudtuk a GUID-ot, az ügyfél előkészítéséhez az 
Active Directory Users and Computers-t használjuk. 
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5 Új azonosító létrehozása 


Ha a ,Create a new computer" (új számítógép létrehozása) opciót 
választjuk, megjelenik a következő párbeszédablak és beírhatjuk a 
számítógép nevét, valamint megadhatjuk azt, hogy az ügyfelet 
ténylegesen ki léptetheti be a tartományba. Alapbeállításként ez 
Domain Admins, ha ezt így hagyjuk, akkor hiába készítjük elő az 
ügyfélgép accountot, a RIS telepítés nem fog tudni elkezdődni csak 
olyan account segítségével, aki ennek a csoportnak a tagja. Tehát 
ide azt a csoportot kell megadni, amelynek tagja az, aki telepíteni 
fogja a gépet, vagy megadhatunk persze egy felhasználót is. 


HZTTE [2] 


New Object 





The following user or group can join this computer to a domain. 
User or group: 


fpelnetzüserszRIS e ! Change. 


IT Allow preWindovss 2000 computers to use this account 


te [7156] ( cmee 


5 Új számítógép létrehozása. Figyelmesen állítsuk be, ki lesz 
képes csatlakozni ehhez a fiókhoz (change gomb)! 








A következő párbeszédablakban a számítógép GUID-jét kell 
megadnunk (ha a RIS nincs telepítve, ez a párbeszédablak nem 
is jelenik meg). 


If you are creating a computer account for a managed computer, select the 
check box below, and then lype the computers complete GUID. The GUID 
may be found in the system BIOS or posted on the computer case. 
[7 This is a managed computer 

Computers unigue ID (GUID/UUID; 

(100000000-0000-0000-0000-o1) 02 
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Ezt a párbeszédablakot csak RIS kiszolgálókon vagy 
olyan kiszolgálókon és ügyfeleken tudjuk használni, 
ahol előzőleg telepítve lett az adminpak.msi. 
A RIS kiszolgáló a GUID segítségével ellenőrzi, hogy 
az ügyfél létezik-e már az Active Directory-ban. 
Egy GUID egy ügyfélhez tartozhat, ezért ha az ügyfélgépből úgy 
nyerjük ki a GUID-ot, hogy elindítottuk már egyszer a telepítőt, 
akkor először onnan kimásolhatjuk (CTRL--C) a GUID-ot, azt az 
accountot töröljük az AD-ból, majd létrehozzuk egy nekünk 
megfelelő néven, és itt beszúrjuk (CTRL--V) a kimásolt GUID-ot. 
Így biztos, hogy nem rontjuk el a gépelést. 
Ha megadtuk a GUID-ot, akkor a következő párbeszédablakban 
megadhatjuk, hogy melyik RIS kiszolgálót használja az ügyfél. Ha 
manuálisan akarjuk elosztani a terhelést a hálózat RIS kiszolgálói 
között, hogy az egyes kiszolgálók csak a saját ügyfeleik kérését 
fogadják el, akkor itt pontosan megadhatjuk a RIS kiszolgáló ne- 
vét, amelyhez az adott ügyfélnek fordulni kell. Azonban ha ez a 
kiszolgáló nem működik, akkor más sem fogja az ügyfeleket ki- 
szolgálni hiába elérhető még más RIS kiszolgáló is a környéken. 
Ezután jön egy összegző képernyő, és már csak egy Next, és elő 
is van készítve az ügyfélgép azonosítója. 
De nézzük csak meg ezeket a GUID-okat! Ha a BIOS-ból kiolva- 
sott GUID-ot gépeljük be, akkor az így néz ki: 


[7 This is a managed computer 
Computers unigue ID (GUID/UUID): 


12345678901234567890123456789012 


Az összegző ablakban pedig ez jelenik meg: 


This is a managed PC. 
GUID: (78563412-1290-5634-7890-12345678901 2) 
Host Server: any available server 


Nem egyezik azzal, ami itt az összegzésben megjelenik! 
Közelebbről megvizsgálva észrevehetjük, hogy az összegző képer- 
nyőn megjelenített szám első 16 bájtja van megfordítva, a mara- 
dék 16 pedig a helyes sorrendben jelenik meg. Az információ, 
amit begépeltünk (12345678901234567890123456789012), 
"Wire" formátumú (a hálózaton keresztül ebben a formában továb- 
bítódik). Amikor a GUID megjelenik, , pretty print" formátumúvá 
alakul, ami a következőképpen néz ki: 
(78563412-1290-5634-7890-123456789012) 

A GUID-ot mindkét formában beírhatjuk, a program wire formá- 
tumúra alakítja és így menti az ügyfélgép account információi 
közt. A felhasználói felületen a GUID-t mindig ,pretty print" 
formátumban jelenik meg. 
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A szükséges jogosultságok 
Ha a RIS-es telepítést maga a felhasználó fogja a saját felhasz- 
nálói nevével és jelszavával indítani, akkor ahhoz extra jogokat 
kell biztosítanunk, hogy létre tudják hozni a gépük accountját 
a tartományban és hogy be is tudják léptetni azt. Amennyiben 
mi egyáltalán nem készítjük elő az előbbiekben leírt módon a 
gépeket, akkor ahhoz, hogy ezt megtehessék, a következő jo- 
gokra van szükségük az 0U-n, amely az újonnan létrehozott gép 
azonosítóját tárolja: 
"8 Olvasási jog 
2 Számítógép-objektumok létrehozása 
Amennyiben előkészítettük az ügyfélgépek azonosítóit, akkor az 
egyes gépazonosítókhoz kell a következő jogokat rendelni an- 
nak érdekében, hogy a felhasználó azt a saját azonosítójával ké- 
sőbb telepíteni is tudja: 
"8 Az ügyfélazonosító jelszavának változtatása/beállítása 
"8 A számítógépobjektum minden tulajdonságának olvasása/írása 
(Read/write all properties on the computer object) 
-8 A számítógépobjektum jelszavának változtatása/beállítása. 
Ezeket a jogokat nem az objektumot tartalmazó 0U-hoz hanem 
magához a gép azonosítójához kell rendelni! 
Ez lehetővé teszi a felhasználó számára, hogy telepítse rendszerét, 
de csak akkor, ha egy rendszergazda előkészíti a gépazonosítót. 
Tudom, az is elég ritkán fordul elő, hogy a felhasználóra bízzuk 
a saját gépének telepítését, de itt lehet bátran, hisz erre talál- 
ták ki. Ne kelljen előtte ülni, CD-ket adagolni időről-időre, egy- 
szerűen lehet indítani. S ha átszabjuk a varázsló oldalait (erről 
lesz szó a következő részben), akkor magyarul beszél a felhasz- 
nálóhoz. Minden adott ahhoz, hogy valóban a legkevesebb 
beavatkozással telepítsük az ügyfélgépeket. Ám nem szeretünk 
kiadni felhasználóknak extra jogokat, ezért aztán jó megoldás 
az is, ha létrehozunk az AD-ban egy olyan felhasználót, akinek 
semmi más joga nincs, mint a RIS-sel telepített gépeket belép- 
tetni a tartományba, ha azt a rendszergazda előkészítette. Majd 
amikor telefonon keresztül navigáljuk a felhasználót, hogyan is 
indítsa el a telepítőt, akkor egy ártatlan felhasználó azonosító- 
ját kell megadnia, nem a sajátját ahhoz hogy elinduljon a tele- 
pítő. Így a rendszergazdának is a lehető legkevesebb a dolga, 
ugyanakkor nem hoztunk létre újabb biztonsági rést a pajzson, 
amely így is eléggé lyuggatott szegény. 


Dorner Csilla 
MCSE 
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A Windows NT 
és a Windows 2000 


memóriakezelése 
—- más megközelítésben 


A Tech.Net tavaly szeptemberi számában Fóti Marcell ezzel a címmel írt cikket a 
Windows memóriakezeléséről. Az írás az én ízlésem szerint nagyon Windows-pártira 
sikeredett, amit nem mulasztottam el a szerző tudomására hozni. 


A Windows NT és a Windows 2000 memóriakezelése 

Kölcsönös anyázások után győzött a józan ész: kiderült, hogy mind- 
ketten irtózunk a szélsőségektől. Egyikünk sem képzeli azt, hogy 
minden számítástechnikai haladás a Windows-tól ered, de azt is 
bosszantónak tartjuk, amikor egy Linux-hívő a Windows-t gyalázza, 
miközben kedvenc operációs rendszerén a Windows-emulátor fut. 
Végül abban is egyetértettünk, hogy a Windows nem szorul olyan 
dicséretre, amely nem a valódi érdemeit emelik ki, ezért kaptam le- 
hetőséget kritikai észrevételeim publikálására. Nem szeretném 
pontról pontra elemezni a szóban forgó cikket, inkább saját logi- 
kám szerinti megközelítésben világítanám meg a vitatott részeket. 


Az operációs rendszer és a memóriakezelés 

Amíg egy gépen csak egyetlen program fut (ez általában az ope- 
rációs rendszer), övé az összes erőforrás. De ha egy második al- 
kalmazást is elindítunk, akkor osztozniuk kell többek közt a me- 
mórián is. Ez az osztozás nem testvériesen történik, hanem szi- 
gorú alá-fölérendeltségi alapon. Az operációs rendszer átadja az 
alkalmazásnak a szükséges erőforrást (feltéve, hogy van miből), 
a program pedig futni kezd. Az elindított kód azonban nem min- 
dig csak a számára kiutalt területen matat, rossz szándékú, vagy 
rosszul megírt alkalmazások megpróbálhatnak belepiszkítani a 
mások által használt memóriatartományokba is. Az operációs 
rendszer feladata, hogy megvédje magát, ill. biztosítsa, hogy a 
párhuzamosan futó több száz végrehajtási szál tényleg egymás- 
tól elkülönített memóriaterületeket használjon. 

Csakhogy az operációs rendszer nem láthatja előre az egyes prog- 
ramok szándékát, így segítség nélkül nem boldogulna. Segítséget 
pedig csak a processzortól kaphat, attól az eszköztől, amelynek 
módjában áll megvizsgálni minden utasítást, mielőtt végrehajta- 
ná. A processzorgyártók pedig kifejlesztették a multitaszkos kör- 
nyezetet támogató (védett módban futó) processzorokat, ame- 
lyek észreveszik, ha egy program tiltott területre téved, és erről 
értesítik az operációs rendszert. Az operációs rendszer pedig el- 
dönti, hogy mi a teendő. Ebből persze az is nyilvánvaló, hogy vé- 
dett módban a processzor nemcsak az egyes memóriaterületeket 
tudja megkülönböztetni, hanem az ott futó kódok jogait is figye- 
lembe tudja venni. A supervisor privilégiumú operációs rendszer- 
nek több mindent megenged, mint a felhasználói programoknak. 


Virtuális memóriakezelés 
Eddig az operációs rendszer abból gazdálkodott, ami fizikailag a 
gépben volt. A processzor intelligens memóriakezelésének és né- 
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mi háttértárnak a felhasználásával azonban mód nyílik nem léte- 
ző memóriaterületek felhasználására is. Ezt az úgynevezett vir- 
tuális memóriát - amelyből egy rész a fizikai memóriában táro- 
lódik, a többi meg a merevlemezen létrehozott fájlban -, a prog- 
ramok közt szét lehet osztani, aztán szükség szerint csak cserél- 
getni kell a tartalmakat. Ha ráadásul a virtuális memória azonos 
méretű, mondjuk 4k-s lapokra van tagolva, akkor a csereberélés 
is egyszerűbb: a fizikai memóriában ideiglenesen nélkülözhető 
lapokat kilapozhatjuk fájlba, a pillanatnyilag szükségeseket meg 
belapozhatjuk onnan a felszabaduló helyre. (Gyakran a háttértár 
gyorsítása érdekében az operációs rendszer a fizikai memória egy 
részét disk-cache céljára használja, ilyenkor előfordulhat, hogy a 
kilapozás valójában egy másik memóriaterületre történik. Néha 
belapozni is lehet onnan, feltéve, hogy a lap még a cache-ben 
van, általánosságban azonban a lapozás lemezművelettel jár.) 
Nem számít, ha a kód/adat/stack nem összefüggő fizikai memó- 
riaterületre lett betöltve, mert a lapok logikai sorrendjének nyil- 
vántartása alapján laphatár-átlépéskor a processzor az alkalma- 
zást átugratja a fizikailag teljesen máshol elhelyezkedő folyta- 
tó lapra. Ebből a program semmit nem vesz észre, és úgy fut to- 
vább, akár egy folytonos tartományon. Ha pedig olyan lapra tör- 
ténik hivatkozás, amely nincs a memóriában, a processzor lap- 
hibát jelez, az operációs rendszer meg rögtön lapoz. 

A flexibilis memóriakezelés ára viszont a lapnyilvántartás nyűgje, 
és a belőle adódó időveszteség. 4k lapméretnél és 46 virtuális 
memóriánál egymillió lapot kell nyilvántartani. Ehhez az operá- 
ciós rendszernek (Intel processzor esetén) kétféle táblázatot, egy 
PageDirectory-t és 1024 Page Table-t kell vezetnie, ami észreve- 
hetően, de azért nem drámaian rontja a rendszer teljesítményét. 


Alternatív memóriakezelés 

Az Intel processzorai kínálnak egy másik védett módú memória- 
kezelést is, a szegmentálást. Ez éppen úgy biztosítja, hogy a 
párhuzamosan futó végrehajtási szálak egymástól elkülönített 
memóriaterületeket használjanak, mint a VM, csak itt nincs la- 
pozás. Az alkalmazás teljes egészében betöltődik, adatainak 
memóriaszegmenset allokál az operációs rendszertől, aztán te- 
szi a dolgát. Ez a memóriakezelés nyilvánvalóan-gyorsabb prog- 
ramfutást tesz lehetővé, mint a lapozós. 

Ám ha a programok cserélődnek a memóriában, akkor már nem is 
olyan előnyös ez a mód. Az egyes alkalmazások ugyanis különbö- 
ző nagyságú egybefüggő memóriaterületeket igényelnek. A leál- 
láskor felszabaduló tartományok vagy kicsik, vagy túl nagyok a 
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mekkora egy adott terheléssel futó Windows szerver fizikai memó- 


íg" következő induló alkalmazásnak, azaz a memória tö- 
riaigénye. A Windows-nak van minimális fizikai memóriaigénye, 


A redezik. Ilyenkor jön a memória töredezettség-men- 
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7 tesítő Garbage Collector. 


Melyik a korszerűbb? 
Mindkét memóriakezelésnek vannak előnyei és hátrányai, és egy ope- 
rációs rendszer fejlettségét nem az határozza meg, hogy ezt, vagy 
amazt a memóriakezelést használja. Lényeg, hogy a számára optimá- 
list részesítse előnyben. 
A processzor által támogatott memóriakezelésből a Windows a 
lapozós technikát választotta (szeretném hangsúlyozni, hogy a 
VM nem Microsoft, de még csak nem is Intel találmány, használ- 
ták már a Windows előtti időkben is). A választás nem meglepő, 
a Windows esetében a virtuális memóriának van előnye. 
A Windows szerverekkel ellentétben a Novell szerverei dedikált 
szerverek, azaz munkaállomásként nem használhatók. Ha tehát a 
NetWare-t elindítjuk, betöltődik az összes szükséges program (a 
memóriaigény bájtra kiszámítható), aztán jó ideig nem kell a 
konzolhoz ülni. Mi haszna lenne itt a lapozásnak? Viszont ta- 
pasztalatból tudom, hogy vannak (nem a Novell által fejlesztett) 
alkalmazások, amelyek párszori újraindítása szinte ,megöli" a 
NetWare-t: az annyira lelassul, hogy jobb restartolni. (Világos, 
hogy ez nem a Novell hibája, de attól még kellemetlen bír lenni.) 
Az, hogy a Novell is kezd áttérni a lapozásra, számomra nem a 
VM ,magasabbrendűségét" mutatja, hanem azt jelzi, hogy a 
NetWare szerver egyre kevésbé tekinthető dedikáltnak, ami a 
slegendás" stabilitást is érintheti. (Megjegyzem, hogy dedikált 
szerverként extrák nélkül használva a Windows NT-vel hasonlóan 
jó tapasztalataim voltak, mint a Novellel. Évekig hiba nélkül fu- 
tott, persze jóféle vason.) 


Na, akkor most hány mega kell? 
Az eredeti cikk arra a kérdésre kereste a választ a rendszereszkö- 
zök (Task Manager, Performance Monitor) segítségével, hogy 
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ez szerepel a termék dobozán. Minden kliens csatlakozása igényel 
további tárat. Bármely alkalmazás hozzávetőleges igénye becsül- 
hető (biztosan nem nagyobb, mint a kód, valamint az általa hasz- 
nált stack és adatterület együttes mérete) is. Ezek a plusz igények 
azonban a virtuális memóriára vonatkoznak, amit az operációs 
rendszer dinamikusan képez le fizikai memóriára. A Microsoft fej- 
lesztési filozófiája a hardver teljes kihasználását célozza meg, 
ezért az bizton állítható, ha van bőven memória, akkor bent lesz 
az egész, ha meg nincs, akkor darálja a merevlemezt. Az viszont, 
hogy a darálás mekkora fizikai memóriánál kezdődik, legfeljebb 
kísérletileg határozható meg. Ráadásul, hogy a rendszer mikor fut 
elfogadható sebességgel, még szubjektív megítélés kérdése is. 
Amikor valaki számítógép-konfigurációt specifikál, van preferált 
alaplap- és processzorgyártója, CD-olvasó- és merevlemezmárká- 
ja, egyáltalán minden komponensről meggyőződéssel meg tudja 
mondani, hogy melyik típus a tuti, csak a memóriamodulokról be- 
szél mindenki kizárólag méretük alapján. Pedig a Windows na- 
gyon intenzíven használja a memóriát, így egyáltalán nem mind- 
egy, hogy mennyire megbízható az, ami a gépünkben van. Tudni 
kell, hogy a memóriaműveletek, különösen az írás nagyon precíz 
összhangot igényel az alaplap, és a memóriamodulok között. Er- 
re a pontos együttműködésre az olcsó RAM-ok nem mindig képe- 
sek tartósan, ez pedig az egész rendszer stabilitására is kihat, ami 
különösen egy szervernél kínos. (A NetWare nem ennyire kényes, 
hiszen ott nincs intenzív lapozás.) Tapasztalatból mondom, hogy 
a Windows lefagyások túlnyomó részét a nem megfelelő memória- 
működés okozza. Ne feledjük tehát, az azért nem az operációs 
rendszer hibája, hogy valakit a hardverkereskedő , begagyizott". 
(Lásd még: Farkasokkal Netmonozó, 8. oldal. A szerk.) 


Tóbiás Ferenc 
ftobias 2elender.hu 


http://vilagokorseg.hu 







JA. NEM AZÉRT, DE 
A FŐNÖK MÁR CSAK 
A NEVÜK MIATT IS 

GYANAKODHATNA... 


008. 05. 


SPAM — jó vagy rossz? 


Lehetséges válaszok 


A spam mibenléte, az erre vonatkozó eddigi, jelenleg hatályos illetve a mindjárt 
hatályba lépő szabályozás alapos áttekintése megérdemel annyi energiát az olvasótól, 
amennyit az elolvasása igénybe vesz, mivel a jogi megközelítés változása igen 
tanulságos az Internet jogi szabályozásának egészét tekintve is. 


A spam kérdése, előnyei vagy hátrányai, megengedhetősége, ke- 
zelése az utóbbi időkben egyre nagyobb vihart kavart a Lajtán 
innen és túl is. Itthon a december utolsó napjaiban az Ország- 
gyűlés által - a több bizottsági fordulóban benyújtott módosító 
indítványok, és a tervezet alapos átgyúrása után - végül a kor- 
mánypártok és az ellenzéki pártok együttes támogatásával elfo- 
gadott elektronikus kereskedelmi törvénnyel kapcsolatban került 
előtérbe a kérdés, míg az Európai Unióban a készülő új adatvé- 
delmi irányelv során , dobták fel" a labdát. Úgy tűnik, hogy a kér- 
dés mindkét jogi normában egybecsengő rendezést nyert, így a 
jelen írás megjelenésekor már jogtörténeti jellegű lesz, hiszen a 
témát rendező jogi szabályozás 2002. január 23-án hatályba lép. 


Mi a spam? Ide sorolunk-e minden olyan e-mailt, amely posta- 
ládánkba naponta beesik, és a legkülönbözőbb dolgokra próbál- 
ja figyelmünket irányítani? A fogalom a kialakult egységes meg- 
közelítés szerint nem minden ilyen e-mailt sorol ide, csak a ké- 
retlen, üzleti célú, többnyire tömegesen, elektronikus úton el- 
küldött üzeneteket. Tehát a pusztán figyelemfelhívó, pl. vallási 
térítési szándékkal küldött e-mail nem tartozik ebbe a körbe. 
Így az egyik sokat vitatott egyház által küldött kéretlen töme- 
ges e-mail nem spam, és amint látni fogjuk, hatályos jogi sza- 
bályos sincs és a közeljövőben nem is lesz az ilyen jellegű e- 
mailekre. A spam tehát csak az, ami üzleti célból érkezik, és 
anélkül, hogy ezt kérném. (Amint látni fogjuk, a jogalkotás 
ugyancsak megkérdőjelezte a spam kéretlenségét, tehát gyakorla- 
tilag az üzleti célú e-mailre szűkült a fogalom.) 


A spam azért vált meglehetősen gyorsan közkedveltté a reklá- 
mozók körében, mert küldője számára olcsó, hatékony, gyors és 
nagy tömegben juttatható el a célszemélyekhez. Egy kutatás 
szerint, amíg a hagyományos direkt marketing egy küldemény- 
re lebontott költsége 0,5-1 USD, addig az e-mailé 10 cent, 
ezzel szemben a direkt marketing hatékonysági mutatója a 
0,5-29o, az e-mailé viszont 5-159o. (Forrás: dr. Jóri András, 
Unsolicited Commersial Communications and DP. EU Commission, 
Internal Market DG, 2001.) (Ha ez így volna...! A szerk.) Kétség- 
telen tehát, hogy mennyivel előnyösebb az elektronikus levél a 
reklámozó számára, mint a hagyományos direkt marketing. És 
akkor még nem is beszéltünk arról, hogy mennyivel könnyebben 
és gyorsabban juttatható célba az e-mail, mint a hagyományos 
postai levél. A spam melletti érvek bővülnek még azzal is, hogy 
itt nem termelődik olyan mértékű papírszemét, mint a hagyo- 
mányos reklámnál, gondoljunk csak arra a tarka papírhalomra, 
amely a lépcsőházakban keletkezik hetente a reklámújságokból. 
A spamnek azonban van olyan hátránya is, amely a klasszikus 
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papírreklámnak nincs: itt a költség jelentős része a címzettnél 
keletkezik, aki ugye rendszerint nem kéri, sőt rögtön a virtuális 
szemétládájába továbbítja a reklámokat. Bizony bosszantó, ami- 
kor a még igen drága telefondíj, sőt Internethozzáférési díj 
gyors ketyegése alatt töltődnek le a terjedelmes kéretlen reklá- 
mok. Még ennél is komolyabb ellenérv a spammel szemben 
azonban az, hogy egy bizonyos mennyiségi határ átlépését kö- 
vetően olyan mérvűvé válhat, amely magára az Internetszolgál- 
tatásra, a hálózat biztonságos működtetésére is veszélyes lehet. 
Egyes beszámolók szerint nem ritka a címzettekhez beérkező na- 
pi 30 darab spam sem, amelyek érdekes módon jellemzően távol 
keleti, különösen koreai eredetűek. 


Az érvek és ellenérvek, a különböző lobbiérdekek érvényesülése 
ezidáig két fő megoldási rendszert alakított ki: az opt out és az 
opt in rendszereket. Az opt out megoldás lényege az, hogy a ké- 
retlen üzleti célú levelek küldése mindaddig megengedett, amíg 
a címzett egy erre biztosított módon nem jelzi, hogy a jövőben 
nem kíván ilyen jellegű üzenetet kapni. Az opt in rendszer pont 
fordítva, csak akkor teszi lehetővé üzleti célú levelek küldését, ha 
a címzett előre jelzi, hogy kíván ilyen jellegű üzeneteket kapni. 
A kétféle rendszer kialakulása megelőzte az e-mailek tömeges el- 
terjedését: először a hagyományos marketing egyes formáira adott 
válaszként jelentek meg az európai és a magyar jogalkotásban. 


Az Európai Unióban a telekommunikációs szektorban a szemé- 
lyes adatok és a magánélet védelméről kiadott 97/66/EC Irány- 
elv volt az, amely először rendelkezett az automatikus telefon- 
hívás és fax vonatkozásában - természetes személyek esetében 
- az opt in rendszer alkalmazásáról. Más esetben, tehát a direkt 
marketing más, nem automatikus formájánál, illetve nem termé- 
szetes személy címzettnél a tagállami szabályozásra bízta az opt 
in/opt out közötti választást. Az elektronikus kereskedelemről 
szóló 2000/31/EC Irányelv az információs szolgáltatások kereté- 
ben szolgáltatott üzleti célú üzenetekkel szemben minimális kö- 
vetelményként azt írta elő, hogy magából az üzenetből egyér- 
telműen ki kell derülnie az üzleti célnak, és mind az áru eladó- 
jának, vagy a szolgáltatás nyújtójának, mind az ajánlat jellegé- 
nek egyértelműnek és azonosíthatónak kell lennie. Az Irányelv 
az opt out rendszert preferálta a természetes személyek vonat- 
kozásában, és nem szólt a jogi személyekről. j 


A két elemzett szabályozás tükrében meglepő módon mégis elő- 
retört az opt in rendszer, és a 15 uniós tagállam közül egyhar- 
madában ezt a szabályozást alkalmazták. Így ma opt in rendszer 
szerint lehet direkt marketinget elektronikus úton folytatni 
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Ausztriában, Dániában, Finnországban, Németor- 
o. szágban és Olaszországban. Az Európai Unió egysé- 
ges belső piacának elvét szem előtt tartva elgondol- 
kodtató, hogy az a direkt marketinget folytató cég, 
amely Franciaországban került bejegyzésre az opt out sze- 
rint működhet, míg a Németországban működő versenytársnak 
az opt in rendszer miatt sokkal nehezebb a dolga. A luxembur- 
gi bíróság elé tudomásunk szerint nem került ilyen kereset, de 
érdekes lenne egy olyan bírói döntés, amely az ilyen megkülön- 
böztető tagállami rendelkezést nem minősítené a belső piac 
egységességét, az áruk és szolgáltatások szabad áramlását aka- 
dályozó tényezőnek. Ám úgy tűnik, hogy az Európai Unió meg- 
haladva az eddig szabályozást, fel kívánja számolni a tagállami 
vkétféleséget" a direkt marketing és így a spam szabályozása te- 
rületén. Az Európai Parlament és a Tanács közös irányelve az 
adatvédelemről a sok vita eredményeként az opt in rendszert 
preferálja szemben az opt outtal. Érdekes módon a kontinentá- 
lis országok forszírozták az opt in rendszer egységessé tételét a 
konzervatívnak tekintett Angliával szemben, amely az opt out 
mellett kardoskodott. Anglia azonban fontosnak tartotta, hogy 
az adatvédelmi szabályozás keretében váljék lehetővé az 
Internetezők adatainak biztonsági okokból átmeneti időre tör- 
ténő tárolása. Ez ellen azonban éppen a kontinentális országok 
jogvédő szervezetei léptek fel erőteljesen. A kompromisszum 
azonban megszületett: Európában általánossá válik az opt in, 
míg megengedett az Internetezők adatainak átmeneti időre tör- 
ténő tárolása. (A kérdés csak az, hogy mennyi az az átmeneti 
idő? De az ezen való töprengés egy másik cikk témája lehet.) 


Az Európai Unióba még nem tartozó, de annak szabályozásához 
szükségszerűen alkalmazkodni kénytelen Magyarországon jelen- 
leg négy hatályos jogszabály rendelkezik közvetlenül vagy köz- 
vetve a spam-ről, és egy, 2001. december 24.-én kihirdetett, de 
hatályba csak 2002. január 23-án lépő törvény tűnik rendezni 
egyértelműen a kérdést. 


A személyes adatok védelméről és a közérdekű adatok nyilvá- 
nosságáról szóló 1992. évi LXIII. törvény értelmében személyes 
adat a meghatározott természetes személlyel kapcsolatba hoz- 
ható adat, az adatból levonható, az érintettre vonatkozó követ- 
keztetés. A személyes adat az adatkezelés során mindaddig 
megőrzi e minőségét, amíg kapcsolata az érintett természetes 
személlyel helyreállítható. Az adatvédelmi biztosnak az 
Internettel kapcsolatban kiadott állásfoglalása értelmében a 
törvény logikus értelmezés szerint az e-mail cím és az IP cím 
(sic!) is személyes adatnak minősül. Ez azt jelenti, hogy ezen 
adatok kezelése során be kell tartani mindazokat a szabályokat, 
amelyeket a törvény előír. Így az e-mail címet csak rendelteté- 
sének megfelelően lehet felhasználni - és a spam nem tartozik 
ebbe a körbe, tehát a spam küldése céltól eltérő adatkezelést 
valósít meg. Ne felejtsük el, itt ismét csak természetes szemé- 
lyekről beszélhetünk, vagyis jogi személyek, cégek, szervezetek 
vonatkozásában a védelem nem érvényesül. Érdekes kérdés per- 
sze, hogy a személyes, de egy cégnek delegált domain név alatt 
működtetett e-mail vonatkozásában mi állapítható meg? 
Ugyancsak nem hagyható figyelmen kívül, hogy ha vizsgálódá- 
sunkat kizárólag adatvédelmi szempontból folytatjuk, akkor cél- 
tól eltérő adatkezelésnek minősül az a kéretlen üzenetküldés is, 
amely nem üzleti célú, hanem más okból került elküldésre. Em- 
lékezzünk a cikk elején említett vallási felekezet térítő jellegű 
küldeményeire, amelyek e törvény alapján tiltottak! Mindezek 
persze csak abban az esetben igazak, ha az e-mail cím megszer- 
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zése során sértik meg az adatvédelmi törvény előírásait. Abban 
a - kevéssé valószínű - esetben, ha az e-mail címre véletlen ge- 
neráció során tesz szert a felhasználója, a céltól eltérő adatke- 
zelés nem állapítható meg. Az adatvédelmi szabályok megsérté- 
se egyébként igen súlyos, adott esetben büntetőjogi szankció- 
val is járhat, így az ilyen lépések bizony megfontolandók! A ku- 
tatás és a közvetlen üzletszerzés célját szolgáló név- és lakcím- 
adatok kezeléséről szóló 1995. évi CXIX. törvény lehetővé teszi, 
hogy direkt marketing céljára a felhasználó a nyilvántartásból 
üzleti célra adatot igényeljen, és egyidejűleg előírja egy tilalmi 
lista felállítását, amelyen azon érintettek név- és lakcímadatai 
szerepelnek, akik nem járultak hozzá, hogy személyes adataikat 
e törvényben meghatározott közvetlen üzletszerzési célok vala- 
melyikére felhasználják, vagy megtiltották azok e célból történő 
további kezelését. Igen, kedves olvasó, jól gondolja: ez az opt 
out rendszer! Viszont a törvény csak a név- és lakcímnyilvántar- 
tásra vonatkozik, így sajnos itt csak az analógia miatt került sor 
a megemlítésére, e-mail címekre nem alkalmazható. 


A gazdasági reklámtevékenységről szóló 1997. évi LVIII. tör- 
vény - az Európai Unió elektronikus kereskedelemről szóló irány- 
elvének ismertetett rendelkezéseihez hasonlóan - a reklám ilyen 
mivoltának azonosíthatóságát, a reklámozó egyértelmű (megne- 
vezése, székhelye megjelölése, adószáma feltüntetése) meghatá- 
rozását írja elő, tovább azt, hogy a reklámot csak a környeze- 
tétől elkülönítve szabad közzétenni. A jogszabály nem tesz 
különbséget a reklámhordozó vagy a reklámot továbbító közeg 
között, így az off line vagy on line médiára, az elektronikus kö- 
zegre vagy a hagyományos hirdetőoszlopon közzétett reklámra, 
tehát a spamre is vonatkozik. Kicsit előreszaladva a mondaniva- 
lóban: itt szükséges jeleznem, hogy az elektronikus kereskede- 
lemről elfogadott magyar törvény nem érinti ezeket az előíráso- 
kat, tehát ezek továbbra is hatályban maradnak és vonatkoznak 
valamennyi elektronikus úton küldött reklámra, azaz spam-re. 


A távollévők között kötött szerződésekről szóló 17/1999. (II. 5.) 
Korm. rendelet, amely egyaránt rendezni kívánta a kataló- 
gusáruházakból, a direkt marketing útján, az off line és az on line 
médián keresztül történő értékesítést is, a fogyasztó kifejezett 
hozzájárulását írja elő ahhoz, hogy a gazdálkodó szervezet a szer- 
ződéskötés céljából automata hívókészüléket, illetve távmásolót 
(telefaxot) használjon. A kissé nehezen érthető megfogalmazás 
mögött az Európai Unió ismertetett 97-es irányelvével összhang- 
ban álló opt in rendszer fedezhető fel az automatikusan (emberi 
közreműködés nélkül) tárcsázott telefonhívások vagy küldött fa- 
xok esetében. A rendelet egy másik fordulata azonban minden 
más esetre, vagyis olyan közvetlen kapcsolatot lehetővé tevő táv- 
közlő eszközre, amely nem automata telefonhívás vagy fax, lehe- 
tővé teszi, hogy a fogyasztó kifejezett tiltakozása hiányában 
(vagyis az opt out rendszerre alapítva) a gazdálkodó szervezet 
ilyet használjon. Ez az a rendelkezés, amely ténylegesen jogsze- 
rűvé teszi ma a spam küldését, természetesen figyelemmel az e- 
maileket, mint személyes adatokat értelmező adatvédelmi bizto- 
si állásfoglalásra, és az ebből következő törvényi korlátokra. 


Az év végi nagy hajrában, a jogalkotási dömping keretében fo- 
gadta el az Országgyűlés, és a Magyar Közlöny 2001. december 
24-i számában karácsonyi ajándékként a fa alá is került az elekt- 
ronikus kereskedelemi szolgáltatások, valamint az informá- 
ciós társadalommal összefüggő szolgáltatások egyes kérdé- 
seiről hangzatos címet viselő 2001. évi CVIII. törvényt. A tör- 
vény részletes elemzésére egy másik cikk keretében kerítünk 
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sort, ezúttal csak a spam kérdésének vizsgálata szempontjából 
ismertetjük. A 14. § az információs társadalommal összefüggő 
szolgáltatás felhasználásával küldött reklámokra vonatkozó külö- 
nös szabályok cím alatt megismétli a reklám azonosíthatóságára 
vonatkozó kívánalmat, és határozottan úgy rendelkezik, hogy ki- 
zárólag az igénybevevő (értsd: címzett) egyértelmű, előzetes 
hozzájárulásával küldhető elektronikus úton, levelezés során 
reklám. Tehát a jogalkotási folyamat során a kezdetben a törvény 
tervezetében szerepelt, és az előterjesztőt képviselő, a törvény 
szövegét megfogalmazók által oly harciasan védett opt out rend- 
szerrel szemben győzedelmeskedett az opt in. A továbbiakban 
előírja a törvény, hogy nyilvántartást kell vezetni azokról, akik 
kívánnak ilyen jellegű küldeményeket kapni, és nem szabad olya- 
nok számára reklámot küldeni, akik a meghatározott nyilvántar- 
tásban nem szerepelnek. Azok számára is lehetővé kell tenni, 
hogy a továbbiakban megtiltsák, hogy részükre reklámot küldje- 
nek, akik ezt korábban igényelték, így tájékoztatni kell a címzet- 
tet arról az elérhetőségről, ahol a reklámok küldésének megtiltá- 
sa iránti igényét bejelentheti. A tilalom a reklámozó, a reklám- 
szolgáltató, illetve a reklám közzétevője által küldendő összes 
reklámra vonatkozik. Az opt in rendszer tiszta és körültekintő 
szabályozásával állunk tehát szemben. Az érdekes csupán annyi, 
hogy amíg a 14. § az elektronikus levelezés útján történő reklá- 
mokról rendelkezik, addig a törvény hatályát meghatározó 1. § 
kifejezetten kiveszi a törvény hatálya alól az elektronikus ma- 
gánlevelezést. E logikai rend szerint tehát a spam üzleti célú le- 
velezés. Vagyis az opt in rendszer csak az üzleti célú reklámra 
vonatkozik, és amint említettük, a nem üzleti célú, de kéretlen 
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és tömeges e-mail küldésre nem. Az pedig majd a 
jogalkalmazás dolga lesz, hogy meghúzza a vonalat: 
meddig üzleti a cél és mikortól nem az. 


További érdekes hézagnak látszik, hogy amíg a frissen elfo- 
gadott törvény csak az elektronikus levelezésre vonatkozik, ad- 
dig a kéretlen üzleti célú üzenetek már újabb eszközt: a mobil- 
telefont kezdik felfedezni maguknak. Erre, vagyis az sms-re pe- 
dig nem vonatkozik a XXI. század első évének végén elfogadott 
törvény. Pedig nincs messze az a jövő, amikor majd kéretlen 
sms-ek lepik el mobilunkat és zavarnak meg napi tevékenysé- 
günk közben sokkal nagyobb akadályt okozva, mint a kéretlen e- 
mailek. A Mobilpont már be is vezette a multilevel-marketing 
rendszerben felépített hálózatban, hogy az oda beszervezett vál- 
lalkozók, akik készek reklámtartalmú sms-eket fogadni, minden 
egyes ilyen üzenet után 5 forintot kapjanak. A horog tehát a 
vonzó csalival már ott lóg a piac tavában, és már jócskán akadt 
arra ráharapó hal is, és még nagyobb a még csak pedzegetők szá- 
ma. Nincs azonban már messze az a jövő, amikor a horgon már 
nem lesz csali sem, viszont az egész mobilozó társadalom hízott 
halként lóg majd rajta. De hát a konzervatív jogalkotás mindig 
az események után kullog, így a kérdés rendezése majd pár év 
múlva egy másik jogszabályban fog megtörténni. 


Dr. Mayer Erika 
IKRP Nádas 8 Mayer Ügyvédi Iroda 
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Hm Portszűrés 


IPSec-kel 


Munkánk során sokszor kerülünk olyan helyzetbe, hogy egy kiszolgálót (legyen a feladat 
web, levelezés vagy bármi más) , meztelenül, pőrén kell az Internethez csatlakoztatni. 
Sehol egy jó kis tűzfal, marad az önvédelem. Az már alapszabály, hogy minden 
szolgáltatást, portot, amire nincs szükség, be kell zárnunk, de mégis, hogyan? 


TCP/IP Filtering vs. IPSec Filtering 

A szolgáltatások leállítása nem 10099-osan biztonságos, vala- 
hogy a hálózati forgalmat kellene szűrni. A Windows NT már 
régóta lehetővé teszi az IP forgalom szűrését, bár elég szigorú és 
kényelmetlen korlátozásokkal. A Windows 2000 beépített IPSec 
támogatása - bár nem erre tervezték - ugyancsak képes a háló- 
zati forgalom szétválogatására, mégpedig jóval rugalmasabban, 
mint az egyszerű TCP/IP szűrés. Íme egy összehasonlító táblázat: 





IPSec szű 
Megadott IP címek 
közötti forgalom 


Szolgáltatás 
Hatókör 


s TCP/IP szűrés 
Minden kártya, 
minden IP cím 





Szűrés csak 
portcím alapján 


Forrás IP cím A szabályokban 


beállítható 








Újraindítás Nem, a hatás azonnali (!) Igen 
szükséges? 

Szűrhető Bármi, ami IP Csak TCP, UDP, 
protokoll ICMP 

Válasz a blokkolt Nincs válasz Reset csomag 
csomagokra 


a Főbb különbségek az IPSec házirendekkel és a TCP/IP beál- 
lításokkal történő csomagszűrés között 


Emellett az IPSec házirend - szükség esetén - Windows 2000 tar- 
tományban Group Policy-vel is beállítható, illetve az IPSec háziren- 
dek parancssori eszközzel is konfigurálhatók (ehhez a Resource Kit- 
ben található ipsecpol.exe-re van szükség). A cikk keretében a gra- 
fikus felhasználói felület használatát mutatjuk be, ráadásul nem a 
Group Policy-n, hanem a gépenként külön-külön használható Local 
Security Policy-n, a helyi biztonsági beállításokon keresztül. 


A Local Security Policy 

A Local Security Policy a Windows 2000 (Professional is) helyi biz- 
tonsági beállításait tartalmazza. Az eszközt az Administrative 
Tools menüben találjuk meg (ez a menü Professional-on csak akkor 
látszik, ha a TaskBar tulajdonságai között külön engedélyezzük) . 
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5 A Local Security Policy ablaka, benne az IPSec beállítások 


Ami nekünk érdekes, az az ,IP Security Policies on Local 
Machine" csomópont, illetve az alatta található elemek. 


Mint azt már említettük, az IPSec eredeti célja nem a csomag- 
szűrés, ezért a cikk során nagyon sok mindentől eltekintünk 
majd, ami esetleg a varázslókban szembe jöhet. A lényeg: az 
IPSec Policy Agent nevű rendszerszolgáltatás minden érkező IP 
csomagnál ellenőrzi az aktuálisan érvényes IPSec házirendet (az 
előző ábra jobb oldali részén a három alapértelmezett házirend 
látható, de egyik sincs érvényesítve). Az IPSec házirend (IPSec 
Policy) IPSec szűrőlisták (IPSec Filter Lists) és szűrőműveletek 
(Filter Actions) összerendeléséből áll. Egy házirend később több 
szűrőlistát és műveletet is összerendelhet. j 
Az IPSec Filter List egy vagy több kommunikációs csatorna 
(feladó, címzett IP címe, protokoll, feladó, címzett portcíme) lis- 
tája. A Filter Action pedig vagy Engedélyez (Permit) vagy Tilt 
(Block) vagy pedig bizonyos titkosított kapcsolatot épít fel 
(Negotiate Security). Ezek közül mi az utóbbit nem használjuk, 
a szűrőakciókat tisztán a csomagok tiltására és engedélyezésé- 
re használjuk majd fel. Világos tehát, hogy a csomagszűrés beál- 
lítása sorrendben a következő műveletekből áll: 

8 IPSec szűrőlisták definiálása 

8 Szűrőakciók definiálása 

"2 Szűrők és akciók összerendelése: az IPSec házirend létrehozása. 
Az első két műveletet közös dialógusablakban végezhetjük el, 
amit (az előző ábrán is látható menüben) a ,Manage IP Filter 
Lists and Filter Actions" parancsra kattintva nyithatunk meg. 


IPSec szűrőlista létrehozása 

Összesen két szűrőlistát kell létrehoznunk: 

-8 Egyet, ami az összes protokollt tartalmazza, amit majd enge- 
délyezni akarunk 

-? Egy másikat, ami minden bejövő protokollt tartalmaz, ez fog- 
juk majd tiltani. 


dúUS. UA. 


Nyissuk meg a szűrőlista létrehozására szolgáló dialógust. A lis- 
tában már két előre elkészített szűrőlistát látunk, az AlL ICMP 
Traffic az ICMP forgalom (pingelés és társai tiltására ezt használ- 
hatjuk majd), az ALL IP Traffic pedig a kimenő forgalom definiá- 
lására való (ez utóbbit itt nem fogjuk használni). Kattintsunk in- 
kább az Add... gombra, és máris megjelenik az új IPSec szűrőlista 
definiálására való újabb dialógus! (A példában olyan szűrőlistát 
fogunk létrehozni, ami a 25-ös (SMTP) és a 80-as (HTTP) portot 
tartalmazza) . Adjunk nevet az új szűrőlistának (pl. , Engedélyezett 
protokollok"), majd kezdjük el felvenni a szűrődefiníciókat 

(megintcsak Add... gomb). Erre elindul a New IP Filter varázsló. 

b Forráscímnek (Source Address) válasszuk az ,Any IP Address 
opciót. 

8 Célcímnek (Destination Address) az ,A specific IP Address"-t, 

majd adjuk meg a saját IP címünket. Ha a gépben csak egy há- 

lózati kártya van, választhatjuk a , My IP Address" lehetőséget is. 

Protokolltípusnak válasszuk a TCP-t 

Az IP protokoll portnál a ,To this port" mezőbe vegyük fel a 

kívánt portcímet (25, illetve 80). 

0 A Finish gomb megnyomása előtt jelöljük be az , Edit Properties" 
négyzetet. 

0 A Finish után megjelenő dialógusablak Description oldalán ad- 
junk egy jól értelmezhető nevet a protokollszűrőnek, hiba- 
keresésnél még jól jöhet. 

8 Végül kattintsunk az OK gombra. 

A műveletet ismételjük meg minden egyes protokoll esetén, amit en- 

gedélyezni szeretnénk. A végén valami hasonló listát látunk majd: 
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6 Az IPSec szűrőlista ablaka, benne a két frissen definiált 
szűrővel 


Ha készen vagyunk, zárjuk be az ablakot, és hozzunk létre még- 
egy szűrőlistát, mondjuk , Minden bejövő forgalom" néven. Eb- 
be egyetlen egy filtert vegyünk fel, az alábbi beállításokkal: 

B Forráscím: Any IP Address 

"8 Célcím: A saját IP címünk 

"8 Protokolltípus: Any 

Ha ez is megvan, zárjuk be a dialógusokat, következhet a szű- 
rőakció létrehozása. 


Szűrőakció létrehozása 

A ,Manage IP Filter Lists and Filter Actions" parancsra megjelenő 
dialógusablak Manage Filter Actions oldalán három előredefiniált 
akciót találunk. Ezek közül számunkra a Permit érdekes, ami a tit- 
kosítatlan forgalmat engedélyezi - ez egyrészt nekünk nagyon 
megfelel majd. Viszont hiányzik a blokkoláshoz szükséges akció: 
hozzuk hát létre! Kattintsunk az Add... gombra, erre elindul a Fil- 
ter Action varázsló. Nevezzük el az új akciót, mondjuk , Block"-nak, 
majd a , Filter Action General Options" oldalon válasszuk a Block le- 
hetőséget. Ezzel készen is vagyunk, létrehoztuk a blokkoló akciót. 
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Az IPSec házirend létrehozása 

Ezek után már nem is maradt más hátra, mint a 

konkrét házirend létrehozása. Most válasszuk a már 

sokat emlegetett menüből a Create IP Security Policy 

parancsra, erre rögtön megjelenik a külön e célra készített 

varázsló. Nevezzük el az új házirendet, mondjuk , Packet Filter"- 
nek, a következő oldalon kapcsoljuk ki az , Activate the default 
response rule" opciót. Végül hagyjuk bekapcsolva az ,,Edit 

Properties" mezőt és kattintsunk a Finish gombra. Megjelenik a 

már kész házirend egyelőre üres ablaka. Kattintsunk az Add... 

gombra, erre elindul a , Security Rule" varázsló (emlékezzünk, 
most fogjuk az egyes IPSec szűrőlistákat az akcióval összerendel- 
ni). A varázslóban a következő beállításokat végezzük el: 

"8 A Tunnel Endpoint oldalon hagyjuk az alapértelmezést: 
aThis rule does not specify a tunnel". 

B A Network Type oldalon válasszuk az , ALL network type" lehe- 
tőséget. 

8 Az Authentication Method oldalon hagyjuk az alapértelme- 
zést (esetünkben nincs jelentősége), majd nyugtázzuk az 
esetleg megjelenő figyelmeztetést. 

8 AzIP Filter List oldalon válasszuk ki az ,Engedélyezett Proto- 
kollok" szűrőlistát 

b A Filter Action oldalon pedig a ,Permit" akciót. 

A műveletet ismételjük meg a , Minden bejövő forgalom" szűrőlista és 

a ,Block" akció összerendelésével, és máris készen van a házirendünk: 
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5 A frissen létrehozott IPSec házirend 


A házirend érvényesítése 

Végül nincs más dolgunk, mint nagy levegőt venni, és érvénye- 
síteni a házirendet. Ehhez kattintsunk az MMC konzolban a há- 
zirend nevére jobb gombbal és válasszuk az ,Assign" parancsot. 
Vigyázzunk, a korlátozások azonnal érvényre jutnak! 
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5 A házirend érvényesítése 


Egy jó tanács 

Egy tipikus internetes masina viszonylag ritkán kommunikál kife- 
lé, de előfordulhat (ha például levelet szeretne küldeni). Ha az 
összes bejövő csomagot blokkoljuk, a gépről kifelé is csak azok a 
protokollok mehetnek, amelyeket befelé engedélyeztünk (azaz 
szűrés nem csatornára, hanem ténylegesén a csomagokra érvényes) . 
Ha ezt szeretnénk elkerülni, ne az összes bejövő csomagot blok- 
koljuk, hanem állítsunk össze egy ,feketelistát" a szűrni kívánt 
protokollokból, és azt a szűrőlistát tiltsuk le. Ez persze kényelmet- 
lenebb megoldás, de kompromisszumokat kötni tudni kell. 
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ASP Suli: 


Az Indexing Service 


. Az Indexing Service szolgáltatás - mely a háttérben csendben indexelgeti a 
dokumentumok tartalmát (hogy később azután segítségével kereshessünk közöttük) - 
megtalálható a Windows 2000 minden változatában. Ha a szolgáltatás fut, még az 
egyszerű keresés is felhasználja az Indexing Service-től kapott adatokat, de programozói 
felületének köszönhetően nagyszerűen használható scriptekből is. 


A Windows NT korábbi változataiban külön termékként, az Option 
Pack-ből telepíthető szolgáltatás az Index Server, mely a Win- 
dows 2000-ben az operációs rendszer beépített része lett. Azóta 
a neve is megváltozott kicsit, így lett Indexing Service. A webes 
dokumentumok indexelése egyáltalán nem áll távol a szolgáltatás 
alapcéljaitól, mi sem mutatja ezt jobban annál, hogy már az ,üre- 
sen" feltelepített Indexing Service is tartalmazza a , Web" nevű 
alapértelmezett katalógust, valamint jónéhány, webre optimali- 
zált szolgáltatást. Cikkünkben áttekintjük az Indexing Service 
működését és azt, hogy hogyan használhatjuk ki a szolgáltatás 
előnyeit webes alkalmazásaink fejlesztésekor. 
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o A még , szűz" Indexing Service, és benne az alapértelme- 
zett katalógusok: System és Web 


Mi is pontosan az Indexing Service? 

Az Indexing Service [1] rendszerszolgáltatás, mely helyi és há- 
lózaton keresztül elérhető dokumentumok tartalmát és tulajdon- 
ságait indexeli, tárolja. A Windows 2000 szolgáltatása alapértel- 
mezésben az Office dokumentumok (Word, Excel, PowerPoint, 
stb.) , HTML fájlok, MIME üzenetek (.eml) , valamint egyszerű szö- 
vegfájlok indexelésére képes. Az indexmotor azonban egy jól de- 
finiált interfészen (IFilter, [2]) keresztül képes gyakorlatilag 
bármilyen dokumentum indexelésére, ha valaki megírja a hozzá 
való szűrőt. Ha például a [3] címről letöltjük és telepítjük az 
Adobe PDF IFilter implementációját, az Indexing Service egy csa- 
pásra képes lesz .pdf fájlok olvasására és katalogizálására is. 

A kigyűjtött információkat azután az Indexing Service katalógu- 
sokba szervezi, és mi később ezen katalógusok segítségével keres- 
hetünk az indexelt dokumentumok között. Az Index Server régeb- 
bi verzióit COM kompatíbilis programozói felület hiányában a 
webkiszolgálón csak egy speciális ISAPI filter segítségével hasz- 
nálhattuk (ez az .idg, .ida, .htx fájlokat kezelő idg.dil). Ez a kom- 
ponens ma is megtalálható a rendszerben, de jó pár biztonsági rés 
melegágya, és ma már a legtöbb helyen a használata tiltva van 
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(vagy kellene, hogy legyen). A Windows 2000 Indexing Service 
szolgáltatása szerencsére már tartalmaz rendes programozói 
felületet mind a szolgáltatás konfigurálására, mind pedig a kata- 
lógusok lekérdezésére - a veszélyes ISAPI filter helyett érdeme- 
sebb ezeket használni. Emellett, az Indexing Service tartalmaz egy 
OLE DB Provider-t is, ami azt jelenti, hogy egy-egy ADO kapcsolat 
adatforrásaként meghatározhatjuk az Indexing Service katalógu- 
sait, és azután ADO műveletekkel is lekérdezhetjük azt. Mi itt a 
scriptprogramozói felületet használjuk majd, de látni fogjuk, hogy 
a munkánk során elkerülhetetlen lesz, hogy egy kicsit az ADO ob- 
jektumait is segítségül hívjuk. 


Az Indexing Service működése 


Lekérdezés Indexelés 
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5 Az Indexing Service működésének vázlata 
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Amint az a fenti ábrából is látható, az Indexing Service felada- 
ta kettős: az első feladat a rendelkezésre álló dokumentumok 
indexelése, a katalógusok előállítása, tekintettel arra, hogy a 
katalogizálás után a dokumentumokban esetleg bekövetkező 
változások megjelenjenek a katalógusban is. Ugyanígy reagálni 
kell az indexelt könyvtárakban később létrehozott dokumentu- 
mokra is. Ehhez, amikor csak teheti, az Indexing Service még az 
NTFS fájlrendszer változásnaplóját is igénybe veszi. Ha pedig ez 
nem áll rendelkezésre, marad a dokumentumok időnkénti újrain- 
dexelése. Amikor az Indexing Service egy dokumentumot inde- 
xel, a dokumentumhoz tartozó IFilter szűrő segítségével össze- 
gyűjti a fontosabb jellemzőket (, property"-k: név, cím, méret, 
stb. - az indexelt jellemzők teljes listáját az Indexing Service MMC 
konzolban, a kívánt katalógus neve alatti ,,Properties" pontban 
találjuk). Miután ezzel elkészült, szintén a szűrőtől ,elkéri" a 
dokumentum szöveges tartalmát. A szöveget azután szavakra 
tördeli (elvileg figyelembe veszi a dokumentum nyelvét, és an- 
nak megfelelően át is alakítja a szavakat: megkeresi a szótöve- 
ket, általános formákat, stb. (Például: az , egyelek" szót tartal- 
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mazó dokumentum megtalálható lesz, ha az ,, eszik" szóra kere- 
sünk). A magyar nyelvű modul sajnos nem része a Windowsnak, 
de például a MorphoLogic [4] MorphoStem programcsomagja 
tartalmaz ilyen komponenseket). Miután az optimalizált szólis- 
ta megvan, közülük még el kell távolítani azokat a szavakat, 
amelyek a keresés szempontjából érdektelenek (például névelők, 
számjegyek, stb.). Ezek a szavak (,zajszavak", ,, noise words") 
nyelvenként ugyancsak változók; az egyes nyelvek zajszavait a 
System32 könyvtárban, noise." nevű fájlokban találjuk meg, 
ahol a " helyén a nyelv azonosítója van (pl. noise.fra). A ma- 
gyar persze ismét nincs közöttük (de a MorphoStem azt is felte- 
lepíti). A szavakból ezután végre szólisták készülnek, amelyek 
segítségével végül kereshetünk a katalógusban. 

A keresés során a szolgáltatásban található valamelyik kataló- 
gusban keresünk, a kérdésünket pedig az Indexing Service által 
ismert három lekérdezőnyelv valamelyikén határozhatjuk meg. A 
három lekérdezőnyelv közül az egyik egy SOL alapú, a másik ket- 
tő pedig az Indexing Service saját lekérdezőnyelvének két vál- 
tozata (dialektusa). Itt az Indexing Service Ouery Language 
(Dialect 2) nyelvet fogjuk használni, de akit érdekel a többi, a 
dokumentációban [5] megtalálja. 
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alma fa Az "alma" és a "fa" szavak egyikét vagy mind- 
egyikét tartalmazó dokumentumok 
alma AND fa Az "alma" és a "fa" szavak mindegyikét tartalma- 


zó dokumentumok 








"alma fa" Az "alma fa" szóösszetételt tartalmazó 
dokumentumok 

alma AND Az "alma" szót igen, a "fa" szót viszont nem tar- 

NOT fa talmazó dokumentumok 


alma NEAR fa Az "alma" és a "fa" szót egymáshoz közel tartal- 
mazó dokumentumok 





(Osize - Azok a dokumentumok, amelyek mérete 
20000 8. c 20000 és 100000 bájt között van 
100000 

(oWrite - A 2001. október 1. óta megváltozott 
2001-10-01 — dokumentumok 

alma 8. A .pdf kiterjesztéső dokumentumok, 
(Afilename amelyek tartalmazzák az "alma" szót 

z t.pdf) 


0 Néhány példa keresésre 


Az Indexing Service használata webes környezetben 

Aki hiányolja az ASP példákat, annak biztató hírem van: még 
egy rövid ideig tartózkodunk a kódolástól, de már közel járunk 
hozzá. Az Indexing Service-t ugyanis mindenekelőtt fel kell ké- 
szíteni a webes tartalom indexelésére. 


(Laon ve [Je 5] 
Tree] 


omputer Management (Local) 
6) já, System Tools 
5 gy Storage 
B "Services and Appkcations. 
lj WMI Control 
a services 
1 BÁ Indeing Service 
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5 A , Web" katalógusban definiálhatjuk az indexelni kí- 
vánt, illetve a kihagyandó könyvtárakat 
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windows / 


Ne felejtsük el, hogy a keresést mindig egy-egy ka- 

talógusban végezzük, ezért érdemes az összetartozó 
könyvtárakat közös katalógusba gyűjteni. A , Web" 

nevű katalógus használata nem kötelező, de ha a kód- 

ban külön nem állítunk be valami mást, a keresés ebben a 
katalógusban fog történni. Az ábrán látható, hogy a katalógu- 
sokba ,negatív" könyvtár is felvehető (azaz, a könyvtár tartal- 
ma ne szerepeljen az indexben). Végül vessünk még egy pillan- 
tást a katalógus tulajdonságlapjára is: 


21x] 





General actáro [General 


ajaj] EZTET 
ene] Tuactáng. Generatn [ 


teertátbe Sera Cdrhentátke Setngi 


7. AGA Metmat Shore haz Aatomate ay (TT tndezttez áh ukran etensiona 


ÚF7 Genaáte ábatrazts 


TT nhet elore vetne kom Serice tana notadtntet 673 


Wwy4WSever  fogsawasm 7] 


TT ket above settngi kom Sense 
5 A katalógusok tulajdonságlapja 


Figyeljük meg az első oldal alján található , WWW Server" mezőt! 
Itt kiválaszthatjuk, hogy az adott katalógus melyik virtuális 
webkiszolgáló dokumentumait tartalmazza. Erre azért van szük- 
ség, mert bár az Indexing Service a fájlokat a helyi (valós) 
elérési úttal katalogizálja (pl. ,, C: InetPublwwwrootldir1] 
default.htm"), de - ha tudja, melyik webkiszolgálón található a 
dokumentum - automatikusan tárolja mellé a virtuális elérési utat 
is (pl. ,/dir1/default.htm") . Így a találatok megjelenítésekor nem 
kell külön foglalkozni a korrekt elérési utak kiszámításával. 

A másik fontos beállítás a jobb oldali ábra közepén látható , Generate 
abstracts" opció. Ha ezt engedélyezzük, az Indexing Service minden 
indexelt dokumentumból (legfeljebb az opció alatt meghatározott 
hosszúságú) szövegkivonatot gyárt és tárol a katalógusban, amit a 
találatok megjelenítésekor ugyancsak felhasználhatunk. 











Keresés 
Keresendő szöveg: 
[otfpack Keresés indítása] 
Segítség 
A keresés eredménye: 


21 2001/11. szám - Tech.Net - A Microsoft Magyarország szakmai 
magazinja 

A tartalomból:, II, évfolyam XI. szám, 2001, november. Farkasokkal táncoló 1. Wolfpack annyit teszi 
forkasfalka . wolpack volt a kódnave annak a szoítvernek, amelyet a Mierozoft 1997-ben adott ki, és a 
világ chatterzer varként amart meg. Az a trándék, hogy minél nagyobb vendelkezésre állást lehessen 
bat. 


dofault.asp - 2 találat (27.196) - 12/13/2001. 3:43:27 PM - 11.10 kB 














5 A találatok megjelenítésekor közölhetjük a felhasználóval 
a találati arányt, a dokumentum lényeges adatait, vagy 
akár a szövegkivonatot is 


Számos lényeges jellemző van még, amit az Indexing Service a 
katalógusban tárol, ezekre később még ki fogunk térni. 


Az Indexing Service COM programozói felülete 

Elérkeztünk végre a katalógusokban való kereséshez. Ehhez az In- 
dexing Service COM-kompatíbilis programozói felületét, annak is 
két objektumát használjuk fel majd. Akit érdekel, az Indexing 
Service teljes referenciája a [6] címen érhető el.-A két, általunk 
használt objektum pedig a Ouery és a Utility lesznek. Az objek- 
tumcsalád másik három objektuma (AdminIndexServer, CatAdm, 
ScopeAdm) az Indexing Service adminisztrációjához szükségesek. 
A példaprogramok a [7] címről tölthetők le. Az IndexDemo 
könyvtár tartalmát másoljuk valahova a helyi lemezre, majd ve- 
gyük fel valahova az alapértelmezett webhely alá virtuális map- 


SUE: B2s 
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paként. Ezután a Indexing Service katalógusában el- 
lenőrizzük, hogy a könyvtárbejegyzés létrejött-e au- 
tomatikusan. Kis idő múlva már az MMC konzolba 
beépített kis eszköz segítségével keresni is tudunk 
majd az indexelt dokumentumok között: 
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Indexing Service Ouery Form 
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5 A katalógusok előzetes teszteléséhez elég az MMC konzol 


Első lépésként hozzunk létre egy oldalt (default.asp), ami bekér 
egyetlen keresőkifejezést, majd az elküldi a kereső oldalunknak 
(guery.asp). A lényeges dolgok persze csak ez utóbbi oldalon 
történnek... lássuk tehát a kódot. 


sSearch - Reguest("s") "! Ezt keressük... 


Set oguery - Server.Createobject("IXSSO.duery") 
oduery.Catalog - "leb" 

oduery.Dialect -— "2" 

oduery.duery - sSearch 

oduery.SortBy - "Rank[d], Write[d]" 
oguery.Columns - "DocTitle, Vpath, Path, FileName, 
4 Size, Write, Characterization, Rank, HitCount" 


Set oRS - oguery.CreateRecordset( "seguential") 


If oRS.EOoF Then 
Response.Write "Nincs találat." 
Else 
Response.Write "Találatok:dbr2" 
While Not oRS.EOF 
For Each oField In oRS.Fields 
Response.Write oField.Name 8 ": 
Response.Write oField.Value § "Cbr2" 
Next 
Response.Write "Cbr2" 
oRS.MoveNext 
WEnd 
End If 


A kód nagyon egyszerű. Létrehozzuk a Ouery objektumot 

(, IXSS0.Ouery") , és kitöltjük néhány jellemzőjét. Ezek: 

8 Catalog - a keresni kívánt katalógus neve. Ha nem adjuk meg, 
és IIS van a kiszolgálón, akkor az alapértelmezés is , Web" 

b Dialect - a keresőkérdésben használt dialektus azonosítója 
(az alapértelmezés is a ,, 2") 

8 Ouery - a keresőkérdés maga 

"0 SortBy - a válaszok rendezési sorrendje. A mezőnevek után írt 


voórking vith 
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[d] csökkenő, az [a] pedig növekvő rendezést jelent. A 
sFank" mező a találati arány mutatója, a többi egyszerű do- 
kumentumjellemző 

"8 Columns - a válaszban visszaadandó mezők listája, vesszővel 
elválasztva. Itt tulajdonságneveket adhatunk meg. Azt, 
hogy milyen tulajdonságok léteznek, az Indexing Service 
MMC modulban, a kívánt katalógus alatti Properties pontban 
látjuk. Néhány tulajdonságot az alábbi táblázatban is bemu- 
tatunk, de akit érdekel, a webkatalógusban használható tu- 
lajdonságnevek teljes listájának utánanézhet a [8] címen. 


Jellemző [ie ti 


























Characterization . A dokumentum szövegének néhány száz 
karakteres kivonata 

DocTitle A dokumentum címe (ha létezik) 

FileName A fájl neve 

HitCount A találatok száma 

Path A dokumentum fizikai elérési útja 
(a fájlrendszerben) 

Rank Találati arány (1..1000, a magasabb érték 
pontosabb találatot jelent) 

Size A fájl mérete 

Vpath A dokumentum virtuális elérési útja 
(a webkiszolgálón keresztül) 

Write A dokumentum utolsó módosításának dátuma 


5 Néhány dokumentumjellemző és leírása 


Miután az alapvető adatokat beállítottuk, meghívjuk az objek- 
tum .CreateRecordset() metódusát. Ez a metódus egy paramé- 
tert vár, ami ,seguential" vagy ,nonseguential" lehet, attól füg- 
gően, hogy egy körben feldolgozandó vagy lapokra bontva, 
könyvjelzőkkel, több nekifutásban megjelenítendő Recordsetet 
szeretnénk. A különböző paraméterek hatására létrehozott 
Recordsetek jellemzői: 


, sSeguential" ,nonseguential" 








Kurzortípus Forward Only Static 
(.CursorType) (0) (3) 
Kurzor helye Server Server 
(.CursorLocation) (2) (2) 
Zárolás típusa Read Only Read Only 
(.LockType) (1) (1) 
Lapok támogatása — nem igen 
(.AbsolutePage, 

.AbsolutePosition) 

Könyvjelzők nem igen 
(.Bookmark) 

Kurzor vissza nem igen 
(.MovePrevious) 


5 A különféle paraméterekkel létrehozott Recordset 
objektumok jellemzői 


A Ouery objektum néhány további jellemzője lehet (ezeket még 

a lekérdezés futtatása előtt kell beállítani) : 

"8 .CodePage - A lekérdezésben, illetve tulajdonságnevekben 

használt kódtábla azonosítója (segítséget lásd később) 

"8 .LocaleID - láttuk, hogy az Indexing Service működésében 
fontosak a nyelvi beállítások. Itt beállíthatjuk, hogy a lekér- 
dezés milyen lokállal működjön (de ha nem tesszük, az ASP 
környezetben futó Ouery objektum trükkös módon titokban 


eüu2Z. UZ. 


kiolvassa a böngésző által — a HTTP ACCEPT LANGUAGE fej- 
lécben — küldött értéket) 
"I .MaxRecords - itt megadhatjuk, hogy a válaszként visszaadott 
Recordset legfeljebb hány rekordot tartalmazzon 
A Recordset visszaadása (azaz a .CreateRecordset() metódus meg- 
hívása) után a Ouery objektum bizonyos jellemzői tájékoztatnak a 
keresés futtatásakor fennálló bizonyos tényezőkről. Konkrétabban: 
b .OutofDate - a jellemző értéke True, ha az adott katalógus 
elkészítését az Indexing Service még nem fejezte be (új do- 
kumentumok jöttek létre, meglévők tartalma változott, stb.). 
B .OueryIncomplete - értéke True, ha a keresést az Indexing 
Service nem volt képes maradéktalanul kiértékelni és végre- 
hajtani (például mert a kereső kérdés túl összetettre sikerült) 
.OueryTimedOut - értéke True, ha a keresés nem fejeződött be 
az Indexing Service  MaxOueryExecutionTime konfigurációs 
paraméterében meghatározott idő (alapértelmezésben 10 má- 
sodperc) alatt. Ezt az értéket a Registry-ben, illetve az admi- 
nisztrációs objektumok segítségével módosíthatjuk. Bővebb 
információt az Indexing Service referenciájában találunk. 
Egy fontos metódus maradt még a végére: a Ouery objektum 
.Reset() metódusa törli az objektum belső állapotát, így az újra 
felhasználható lesz a további keresésekkor. 


A Utility objektum 

Az Indexing Service másik, lekérdezéshez használatos objektu- 
ma a Utility (IXSSO.Util). Ez az objektum néhány olyan hasznos 
metódust tartalmaz, amely megkönnyíti a lekérdezések kezelé- 
sét. Az első, és legfontosabb metódus az .AddScopeToüuery(). 


Set oguery - Server.Createobject("IXSS0.Ruery") 
oduery.Catalog - "Web" 
oduery.duery - sSearch 
oduery.Columns - "FileName, Path, Rank, Vpath" 


Set oUltil - Server.CreateObject("IXSSO.Util") 
oUltil.AddScopeToguery oguery, "c:Vindexdemo" 

Amikor a Ouery objektumot létrehozzuk, a keresés alapértelme- 
zésben a teljes katalógusra vonatkozik. A katalógusban történő 
keresést is korlátozhatjuk azonban a katalógus egy vagy több 
elemére (itt scope a neve, de tulajdonképpen a könyvtárakról van 
szó). A Utility objektum .AddScopeTogluery metódusával a lekér- 
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dezést befolyásolhatjuk. A metódust többször is 
meghívhatjuk, így egynél több alkönyvtárat is meg- 
határozhatunk a kereséshez. A metódus paraméterei 

sorra a következők: 

85 Az első paraméter maga a Ouery objektum 

"8 A második paraméterben átadhatjuk a kívánt scope nevét (fi- 


2 A harmadik paraméter elhagyható; ha megadjuk, értéke , deep" 


vagy ,shallow" lehet. Az előbbi esetén a keresést a 

megadott scope alkönyvtáraiban is lehetővé tesszük, a 

Shallow" csak a megadott könyvtár keresését engedélyezi. 
Két további metódus az ASP feldolgozást hivatott segíteni. Az 
ASP Server objektumának .HTMLEncode() és .URLEncode() me- 
tódusai már ismerősek lehetnek. Ezek konverziós rutinok, ame- 
lyek segítenek a szövegek HTML kódba, illetve URL-be illeszthe- 
tő formájúvá alakításában. A Utility objektum két hasonló nevű 
metódust tartalmaz, amelyek az ASP-s változathoz képest kicsit 
fel lettek okosítva. Mindegyik metódus egy-egy plusz paramé- 
tert is hordoz: megadhatjuk (sőt, meg is kell adnunk) a konver- 
zióhoz használt kódtábla azonosítóját. 
A .TruncateToWhiteSpace() metódus két paramétert vár: az első 
egy szöveg, a második egy számszerű érték. A metódus a szöve- 
get elvágja úgy, hogy a vágás szóhatárra essék (azaz nem vág 
félbe semmit), és a visszaadott szöveg legfeljebb a megadott 
hosszúságú lesz. Ezt a metódust például a szöveges kivonatok 
(,, characterization"  dokumentumjellemző) méretre vágásához 
használhatjuk, valahogy így: 


oUtil.TruncateTolhitespace( 
B oORS("Characterization" ) , 200) 


Végére maradt két konverziós rutin: az .IsoToLocaleID() metó- 
dus egy ISO 639 nyelvazonosítót (pl. , hu") lokál azonosítóra 
konvertál (emlékszünk még a OXuery objektum .LocaleID jellemző- 
jére?); míg a .LocaleIDTOISO pont ennek ellenkezőjét teszi. 


oguery.LocaleID - oltil.IsoToLocaleID( 
B Reguest.dueryString( "HTTP. ACCEPT. LANGUAGE" ) ) 


Fülöp Miklós 
mick onetacademia.net 


[1] http://msdn.microsoft.com/library/en-us/indexsrv/indexingservicestartpage 6td1.asp 
[2] http://msdn.microsoft.com/library/en-us/indexsrv/ixrefint 95fm.asp 
[3] http://www.adobe.com/support/downloads/detail.jsp?ftpID-1276 


[4] http://www.morphologic.hu 


[5] http://msdn.microsoft.com/library/en-us/indexsrv/ixglang 92xx.asp 
[6] http://msdn.microsoft.com/library/en-us/indexsrv/ixref 6xid.asp 

[7] http://technet.netacademia.net/download/asp/12/ 

[8] http://msdn.microsoft.com/library/en-us/indexsrv/ixuwebov 1gcn.asp 
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A Wireless Markup Language 


Egy vérbeli informatikus mindenekelőtt hidegrázást kap a csigalassú, legfeljebb 
kétszintű grafikával (ha egyáltalán...) ellátott, 4-5 sorban, soronként 20 karakterben 
megjelenített szolgáltatásoktól, amit ráadásul rendes billentyűzet hiányában minden- 

féle trükkös módon lehet csak használni. Kínszenvedés az egész. A WAP halálra van 
ítélve, mondjuk kórusban. Aztán a kezünkbe kerül az első WAP-os telefon... 


£ owG1 - Openwave! 


Napjainkban egyre elterjedtebbek a WAP-os bön- 
gészőkkel ellátott mobiltelefonok. Ezek a kis esz- 
közök a rendelkezésre álló (gyorsnak nem mondha- 
tó) kommunikációs csatornákon keresztül képesek 
web-szerű szolgáltatások igénybevételére. 

Kacérkodunk a gondolattal: itt a lehetőség. A függő- 
ség bizony komoly dolog. Elmegyünk pecázni a világ 
végére, ahol nincs hálózat, nincs Internet, nincs 
semmi. Térerő azért akad, és lassan rájövünk, hogy 
csak jó lenne tudni, mi történt a nagyvilágban, hogy 
megy-e még a szerverünk, kaptunk-e levelet valaki- 
től, mik a lottószámok (azért a Maldív-szigeteken nem 
ugyanaz pecázni, mint mondjuk a Tiszán... — sőt, ha 
bejön, akár a csónakból foglalhatjuk a repülőjegyet :-) ), 
vagy mondjuk hogy mit jelent a ,cucko" magyarul. 
Végül pedig - hacsak még nem esett a vízbe a csó- 
nakról - előkerül a kütyü. A WAP tehát él. Rejtőzkö- 
dik, aztán lesből támad. Mi pedig áldozatok vagyunk. 
Addig jó, amíg nincs WAP-os telefonunk :-) 





A WAP kommunikáció 

A WAP önmaga a telefonkészülék és a szolgáltatónál található 
WAP-os átjáró (gateway) közötti kommunikációt jelenti. A kom- 
munikáció tárgya pedig a mobiltelefonokra optimalizált webes 
tartalom, amit rendszerint egy, a HTML-hez hasonló, de optima- 
lizált nyelven, a WML-ben írjuk le. A WML egy (nagyon!) szigo- 
rúan definiált XML formátum. Erre azért van szükség, mert a 
WAP gateway a kiszolgálótól érkező WML tartalmat tömöríti, tok- 
enizálja, bináris kódra fordítja, és csak ezt a bináris eredményt 
küldi el a telefonnak. Az automatikus fordításhoz pedig szigorú 
szintaxisra van szükség (a dolog finomsága az, hogy az esetleges 
szintaxishibák a gateway-en derülnek ki, és se a kiszolgáló, se a te- 
lefon nem értesül a hiba pontos jellegéről. ..). A WML-t kifejezet- 
ten a mobiltelefonok kijelzőjére és a korlátozott adatbeviteli 
eszközökre optimalizálták. 


Kódolt kérés HTTP kérés (URL) újáji 
az scriptek 
E GSM hálózat Ködegektés Internet stb. 
d dekőderek 
Ködolt válasz HTTP válasz Tartalom 
Gateway (text/vnd.wap.wmj 


Ügyfél Webkiszolgáló 
(telefon) 


50 Egy átlagos WAP-os kommunikáció vázlata 
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ela A fenti vázlatból is látszik, hogy a gateway és a ki- 
szolgáló közötti kommunikáció a szabvány HTTP 
csatornán (TCP 80 port) , szabványos formában zaj- 
lik (tehát, egy hagyományos IIS is képes WAP-os 
szolgáltatásokat nyújtani). Az egyetlen dolog, 
amire figyelni kell, hogy az oldalak MIME típusa 
(, formátuma") ne text/html, hanem 
text/vnd.wap.wml legyen. Ezt a script kódjából, és 
külső konfiguráció segítségével is elérhetjük, de 
ez egy következő cikk témája. Miután a gateway 
megkapta a kódot, , lefordítja" és továbbítja a ké- 
szülék felé. Ennyi az egész. 

A feladat már csak az, hogy előállítsuk a megfele- 
lő dokumentumokat. A dokumentumok leírásának 
nyelve pedig a WML. Ugyanolyan könnyű WML ol- 
dalakat előállítani, mint HTML-t, csak kicsit más a 
nyelvjárás. 


Wireless Markup Language (WML) 
A WML tehát mobileszközökre (és nem feltétlenül 
csak telefonokra, hanem PDA-kra és egyéb kütyükre — 
közös jellemzőjük a korlátozott képességű I/O eszközök, és a lassú, 
esetenként nagy késleltetési idejű hálózati kapcsolat) tervezett do- 
kumentumleíró-nyelv. Cikkünkben a ma talán legelterjedtebben 
támogatott WML 1.2 [1] verzió alapjait mutatjuk be, de akit a 
konkrét referencia, a napi változások, illetve a további WAP szab- 
ványok népes családja érdekel, bátran látogasson el a WOPforum- 
.org [2] weblapjára. 
A WML nyelv elemeit négy fő csoportra oszthatjuk: 
"8 WML struktúraelemek - amelyek magának a 
WML dokumentumnak a létrehozásához szükségesek 
8 Szövegmegjelenítés és formázás - néhány, a 
HTML-ből már ismert karakter - és szövegformázó elem 
"2 Navigáció és hiperlinkek - kapcsolatok, 
hivatkozások WML dokumentumon belül és oldalak között, 
természetesen az elmaradhatatlan kérdőívekkel és elemekkel 
8 Szöveges paraméterek és állapotmenedzsment - a WML nagy 
előnye, hogy a böngésző képes a WML kódba ágyazott vál- 
tozókat futás közben kiértékelni és feldolgozni 
Ne felejtsük el, hogy a WML valójában egy szigorú XML dokumen- 
tum, így menet közben be kell tartanunk az XML szintaktikai 
előírásait. A leggyakoribb hibák (HTML programozók, figyelem!): 
"8 Az XML formátum érzékeny a kis- és nagybetűkre! 
"8 Az elemek attribútumait minden esetben idézőjelek (") 
vagy aposztrófok () közé kell írni 
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b Mindig minden elemnek van záró tagja. A nyitó tag lehet 
egyben a záró tag is, ilyenkor az XML-ből ismerős formátu- 
mot kell használni (figyeljük meg a / jelet az elem végén), pl: 


La href-"index.wml"2Ennek van záró tagjak/a2 
illetve 
£br/2 vagy Cimg src-"kep.wbmp" alt-"kep"/2 


"8 XML-ben az elemek nem fedhetik át egymást, tehát az 
alábbi példa WML-ben is hibás: 


Su2ci2c/ukziz 


b Kötött, hogy mely elemek mely más elemeket tartalmazhat- 
nak! Ezért jó, ha mindig kéznél van egy jó kis WML referen- 
cia, ha nem is rögtön a specifikáció. A [3] címről egy rövid, 
tömör WML referencia tölthető le, PDF formátumban. 

Aki wapos oldalakat fejleszt, hamar rájön, hogy egy jó fejlesz- 

tőeszköz nélkül nem fog sokra menni. Hiába a mobiltelefon, a 

hibákból csak annyit látunk, hogy valami nem fog működni. 

Hiába a Windows-os wapböngésző, ha az meg közvetlenül dol- 

gozik a WML kóddal. Kellene egy , hamis" gateway is, ami a sze- 

münk láttára fordítja le a kódot, és akkor végre láthatjuk, mi 

történik majd a mobilszolgáltatónál (is). Egy ilyen, nagyon kel- 

lemes, és ingyenes eszköz az Openwave SDK [4], amely többek 
között egy wapos gatewayt, és a cikk elején látható mobiltele- 
fon-emulációt is tartalmaz. A Nokia fejlesztői fórumának web- 
oldalán [5] pedig ingyenes regisztráció után részletes WML re- 

ferenciákhoz, telefondokumentációkhoz, emulátorokhoz (pl. a 

komplett Nokia Mobile Internet Toolkit-hez) juthatunk. Ilyen se- 

gítség nélkül nem érdemes nekikezdeni a munkának. 


Fontos! A telefonok memóriája korlátozza a letölthető WML 
fájlok méretét. Az átlag ma az 1.3 kilobájt (a Nokia telefo- 
nok specifikációját ugyancsak az [5] címen lehet megtalál- 
ni), amit a tömörített, bináris adatfolyamra kell érteni. Az 
emulátorok általában jelzik, hogy a WML kódból mekkora 
bináris csomag jött létre. Ennél nagyobb desk-ek letöltése 
hibát fog okozni, ezért óvakodjunk tőle! 


A WML fájl formátuma 
A tipikus , Helló Világ" alkalmazás WML-ben így néz ki: 


€X?xml versions"1.0" encoding-z"utf-8"?2 

LIDOCTYPE wml PUBLIC "-//UAPFORUM//DTD UML 

4 1.2//EN" "http://www.wapforum.org/ 

$ DTD/wml.D.1.xml"2 

Xwmi2 

card id-"cardl" title-"UAP teszt"? 
£p?Helló Világ!c/p2 

£/card2 

£/wm1l2 


Az első sorban láthatjuk a kötelező XML fejlécet, benne utalással a 
tartalom kódolásához használt kódtáblára. Itt használhatunk az utf- 
8-on kívül más kódolást is, ha arra lenne szükségünk. A következő 
sor (!DOCTYPE) a WML szintaxisát definiáló DTD fájlra mutat. Ezután 
pedig, a Cwm12 elem megjelenésével, az oldal leírása következik. 

Egy WML oldal egy vagy több kártyát (card) tartalmazhat (emiatt 
a WML fájlokat az angolban WML deck-nek (kártyacsomagnak) is 
nevezik). A kártya (amit a £card? elem definiál) egy ,oldalnyi" 
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logikailag összetartozó szöveges, formázó, és adatbe- a 
viteli elemeket tartalmaz. Egy kártya nem feltétlenül 4 A 


egy telefonképernyőnyi adat, egyszerűen csak egy- 

ségként kezelendő elemek összessége. A letöltés (kom- 
munikáció) egysége viszont mindig a deck, azaz a komplett 
WML fájl. A linkek, hivatkozások egyaránt mutathatnak egy deck 
adott card-jára (ilyenkor a £kcard2 elem "id" attributumának ér- 
téke egy $ jel után belekerül a hivatkozásba — mint HTML-ben a 
bookmark) , vagy mutathatnak magára a deck-re is (ilyenkor a fáj- 
lon belül található első kártya fog megjelenni) . 

Lássunk egy példát, ami három kártyát tartalmaz! (Terjedelmi 
okokból az XML és DOCTYPE fejlécet ezentúl nem jelezzük, de je- 
gyezzük meg, hogy mindig ott a helyük!) 


€Kwm12 
£Kcard id-"cardl" title-"WAP teszt"? 
£XpPElső oldal. 
£a href-"tcarde"?Tová bb. . .£/a2c/p2 
£/card2 
£Kcard id-"cardd" title-"WAP teszt"? 
£XpPMá sodik oldal. 
ga href-"tcard3"?Tová bb. . . C/a2K/p2 
£/card2 
£Kcard id-"card3" title-"WAP teszt"? 
£Xp2Harmadik oldal. 
£Xa href-"tcardl"?Tová bb. . . €/a2C/p2 
c/card2 
£/um12 


A bekezdések jelölésére való £p? és a hivatkozások létrehozásá- 
hoz használatos ca2 elemet a HTML-ből ismerhetjük. Nézzük 
meg az ca? elem href attribútumát, azaz a hivatkozás cél- 
pontját! Az egyes kártyákra a fájlon belül a kártya azonosítójá- 
val hivatkozunk, pl.: 


Za href-"tcarde"o?Tová bb. ..€/a2 


Ha pedig ,kívülről", más oldalról szeretnénk egy fájl (nevezzük 
mondjuk ,,cards.wml"-nek) adott kártyájára mutatni, ezt kell írni: 


Za href-"http://wap.falatrax.hu/cards.wmlttcarde"2 
Tová bb. ..€/a2 


A chead:, cmeta: és caccessz elemek 
A HTML-hez hasonlóan a WML dokumentumnak is lehet fejrésze. 
A chead? elem segítségével, közvetlenül a Cwm12 elemen belül 
definiált fejrész különféle információkat tartalmazhat az oldalra 
vonatkozóan. Ezeket a metainformációkat £head? elemen belül 
definiálhatjuk a következő két elem segítségével: 
Az Saccess? elem segítségével korlátozhatjuk, hogy egy WML 
fájl letöltésére honnan érkezhetnek kérések (azaz, a felhaszná- 
ló milyen címről juthat el az adott oldalra). Ezzel egy bizonyos 
szinten korlátozhatjuk a wapos oldalainkhoz való hozzáférést. 
Az Saccess? elem két attribútuma az alábbi lehet: 
"b domain, path - mindkét jellemzőnek szöveges 
értéket adhatunk. A domain attribútum értéke a hívó oldal 
kiszolgálójának tartománynevét, a path pedig a hívó oldal 
A cmeta2 elem különféle egyéb metainformációk definiálását 
segíti, a fontosabb attribútumok: 
"8 name - a tulajdonság neve 
B http-eguiv - mint a name, de ha ezt használjuk helyette, 
akkor a kiszolgáló (vagy a WAP gateway) HTTP (WSP) fejlé- 
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cet hoz létre az itt meghatározott adatok alapján 

"B content - a tulajdonság értéke 

"8 forua - ha értéke true, akkor a beállított adat 
a böngészőnek szól (különben nem éri el, mert a WAP 
gateway feldolgozza és eltávolítja azt) 


cXwmi2 
xhead2 
daccess" domainz"myorg.hu" path-"/mypath"/2 
Xcmeta http-eguiv:"Cache-Control" 
content-"max-age-D"/2 
€/head2 
€Kcard id-"c1l"2Cp2Helló Világ!C/p2kg/card2 
€/wml2 


Szövegformázó elemek 

A WML is tartalmaz a HTML-hez hasonló szövegformázó elemeket. 

Az alapvetőbbeket (bekezdés, sortörés) a legtöbb kliens ismeri, de 

több olyan elem is van, amelyek hatásában nem lehetünk bizto- 

sak. Ne feledjük, hogy a WML egyelőre nem a csillogásról szól... 

B €p2...£/p? - Bekezdés határait jelöli. A HTML-lel ellentétben 
itt mindig minden bekezdésnek vége is van, tehát a záró 
£/p? elemet mindig kötelező kirakni. Minden kártya tartal- 
maz legalább egy cp? elemet, mert a card? elem csak ezt 
az egy szövegformázó elemet tartalmazhatja (ezen belül az- 
tán már jöhet a többi is). A Sp? elem align attribútuma a 
szöveg balra (, left"), jobbra (,right") vagy középre (,,cen- 
ter") rendezését jelezheti, pl.: 


£p aligns"center"2Helló Világ!C/p2 


A mode attribútum értéke (,wrap" vagy ,nowrap") azt jelzi, 

hogy a bekezdés tartalma sorokra tördelhető-e, avagy sem (ha 

ez lehetséges). 

B cbr/2 - Sortörés (egyben nyitó és záró tag is, soha ne 
felejtsük el kiírni a / jelet a végére!) . 

"B cb3...£/b3 - Vastag betűvel megjelenítendő szöveg 

B ci2...§/i2 - Dőlt betűs szöveg 

"B €u3...§/u3 - Aláhúzott szöveg 

B cbig2...€/big2 - Nagyobb betűméret 

"0 Csmall5...€/small; - Kisebb betűméret 

A gem3...£/em3, Cstrong2 ...£/strong? - Általános szöveg- 
kiemelés (hacsak nincs kifejezetten szükségünk egy-egy adott 
szövegkiemelési típusra (dőlt, aláhúzott, stb.), használjuk he- 
lyette ezeket az elemeket) 


Speciális karakterek 

A kódban előforduló speciális karaktereket már a HTML-ből is isme- 
rős kódolt formában lehet és kell írni. Az XML szintaxisban fontos 
szerepet játszó jeleket kötelező így írni, míg a hagyományos karak- 
tereket (pl. ő, ű, stb.) az Unicode-nak vagy más használt kódtáb- 
lának köszönhetően nem muszáj. Amit viszont feltétlenül kell: 


Jel Kód 

n 8guot; 84834; 
y !  §apos; 8t39; 
a gamp; 8438; 
Ms alt; 8tbO; 
3 egt; 8tb2; 
$ ss 


5 Gyakran használt jelek és kódjaik WML-ben 
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Különös figyelmet érdemel a dollárjel. Később még lesz szó ró- 
la, de a $ jel WML kódban mindig egy változó nevének kezdetét 
jelöli, aminek az értékét az oldal megjelenítése közben maga a 
böngésző értékeli ki. Ezért, ha egyszerű dollárjelet szeretnénk 
írni, azt a szövegben meg kell kettőznünk. A másik érdekesség 
az, hogy a 8 jel még az URL-ekben sem szerepelhet kódolatla- 
nul, tehát az alábbiak közül csak a második sor helyes: 


da href-"index.wm1l?a-láb-2"2klikkk/a2 
ga href-"index.wml?a-láamp;b-2"2klikkk/a2 


Táblázatok 

Nem tévedés, alapvető formázási 
célokra használhatunk táblázato- 
kat is. A WML erre a HTML-ből 
már ismerős táblázat (Ctable2 ), 
sor ( £tr5 ) és cella ( Ctd2 ) ele- 
meket használja. A Ctable2 
elem csak £tr2-t, ez utóbbi pe- 
dig csak £td2 elemet tartalmaz- 
hat, a cella tartalma pedig formá- 
zott szöveg lehet (cp? például 
nem). Az itt látható formációt 
például az alábbi kódrészlet se- 
gítségével hoztuk létre: 





table title-"Teszt" columnsz"3" align5s"RCL"2 
£tr2 
£td2--1--€/tdogtdobC/td2Ctd23c/td2 
£/tr2 
£tr2 
£xtd2dC/td2Ctd2--5--CK/tdogtdofcC/td2 
£/tr2 
£tr2 
£td27£/td2ktd2hC/td2ktd2--73--C/td2 
£/tr2 
c/table2 


A példa azt hiszem magáért beszél. A három elem közül csak a 

£table? rendelkezik fontosabb attribútumokkal: 

B columns - a tábla oszlopainak száma, kötelező megadni. 
Értéke nem lehet 0. . 

"0 align - a cellákban található szöveg rendezése, oszlopon- 
ként. Minden oszlopnak egy betű felel meg, ami lehet , L" (bal- 
ra, alapértelmezés) , ,C" (középre), vagy ,R" (jobbra) rendezés 


Navigáció 

A legegyszerűbb navigációs elemről, az £a2-ról már ejtettünk 
pár rövid szót az előző oldalakon. A WML azonban jóval össze- 
tettebb eseménykezelő és navigációs elemeket is tartalmaz 
(még szerencse, mert mire mennénk például kérdőívek nélkül?) . 
Mint minden böngésző, a wapböngésző is tárolja bizonyos ideig 
az addig bejárt oldalak címeit. Ha akarjuk, később ebben a lis- 
tában navigálhatunk oda-vissza, vagy törölhetjük azt. Az egy- 
szerű navigáció elhelyezi az aktuális oldal címét a history-ban, 
míg prev művelet például leveszi az utolsó előttit és megnyitja 
azt. Ebben a tekintetben az egyszerű hiperlinkre , kattintás" is 
csak egy esemény, ami egy navigációs műveletet (task) vált ki. 
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A műveletek 

Négyféle művelet létezik, ezeket egy-egy WML elem személyesí- 

ti meg. A művelet további jellemzői értelemszerűen az elemek 

attribútumaként állíthatók be. Ezek az elemek, az egyszerűtől a 

bonyolultabbig, az alábbiak lehetnek: 

2 €noop/2 - nincs művelet (bármilyen furcsa is, még ennek is 
van értelme) 

B Crefresh/5 - az oldal frissítése, újbóli megjelenítése a vál- 
tozók tartalmának újbóli kiértékelése után 

B €prev/5 - visszalépés a historyban 

B €go2 - navigáció és/vagy kérdőív-adatok küldése 

Ez utóbbi elemet tárgyaljuk ki egy kicsit részletesebben. A £g02 

elem többek között az alábbi attribútumokat tartalmazhatja: 

B href - a cél URL-je 

B method (,GET" vagy ,POST") - A HTTP kérés típusa, mint a 
HTML-ben. , GET" esetén az esetleges paramétereket az URL, 
míg ,POST" esetén a HTTP kérés törzse tartalmazza (ez utób- 
bit pl. kérdőívek küldésénél kell használni) 

"b sendreferer (, true" vagy , false") - ,true" értéke esetén a 
kérésben benne lesz az aktuális oldal címe 

A cgo2 elem egy vagy több Kpostfield? elemet is tartalmaz- 

hat. Ezek az elemek definiálják a HTTP kérésbe kódolandó vál- 

tozók nevét és azok értékét (tehát pl. egy kérdőív által össze- 

gyűjtött adatokat). Két példa, egyelőre kérdőív nélkül: az első 

egy ,/index.wml?x-1" tartalmú HTTP kérést generál: 


£go href-"index.wml" method-"get"2 
$gpostfield name-"x" valuez"1"2 
£/go2 


A következő pedig v1 és v2 értékét a HTTP kérés törzseként kül- 
di el (a, POST metódusnak köszönhetően): 


£Xgo href-"index.wml" method-"post"2 
value-"100"2 
value-"20D"2 


£Xpostfield namez"vl" 
gpostfield name-z"ve" 
£/go2 


A műveletek azonban nem járnak csak úgy, egyedül. Ahhoz, 
hogy a felhasználó kommunikálhasson az oldallal, , parancso- 
kat" kell definiálnunk. Egy-egy parancs a böngészőtől függően 
megjelenhet grafikus elem (gomb), előre definiált nyomógomb, 
vagy menüből kiválasztható utasítás formájában, a lényeg, hogy 
a felhasználó valamilyen módon arra hivatkozhat. A parancs ki- 
választása után végrehajtódik a hozzárendelt művelet. 


A cdo? elem 

A parancsok általános definiálására a cdoz elem való. Az elem 

feladata tulajdonképpen csak az, hogy megértesse a böngésző- 

vel, hogy az általa tartalmazott műveletet milyen formában 
ajánlja fel a felhasználónak. Itt definiálhatjuk például azt, hogy 

mi lesz az a felirat, amit a böngésző megjelenít. Az elem leg- 

fontosabb attribútumai: 

"label - a parancs neve. Ez az a szöveg, ami megjelenik majd 
a felhasználó előtt. Próbáljuk minél rövidebbre fogni, az ajánlott 
hosszúság legfeljebb 6 karakter (hosszabb is lehet, csak a böngé- 
szón múlik, hogy mit kezd vele) 

"8 type - a parancs típusának definiálására azért 
lehet szükség, mert előfordulhat, hogy a böngésző (vagy az 
eszköz) előre definiált funkciókat tartalmaz (pl. az OK gomb 
mindig egy adott helyen található). Ha a böngésző tudja, 
hogy az éppen definiált parancs tulajdonképpen egy OK 
(vagy másik példa: mondjuk egy ,, HELP"), akkor megfelelően 
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el tudja azt helyezni. Több előre definiált típus 
is létezik, de a böngészők bármit elfogadnak, 
legfeljebb ismeretlenként (alapértelmezettként) 
értelmezik azt, pl.: 


a 
ka 


azznatattáttátáae 


accept Jóváhagyás, elfogadás, OK 

prev Navigáció visszafelé 

help Segítség kérése 

reset Valamilyen állapot törlése, visszatérés alapállapotba 
options Egyéb műveletek, opciók indítása 

delete — Elem vagy választás törlése 


unknown Ismeretlen (alapértelmezett) 


Jegyezzük meg, hogy az attribútum értéke csupán formalitás, a 
parancs ,elhelyezésében" segít az eszköznek, önmagában nem 
végez műveletet (azaz, pl. egy , prev" típusú £do2 elemmel nem 
lehet navigálni, ehhez kell majd egy £prev/2 művelet is). Ha 
tehát oldalunkba egy , Vissza" feliratú parancsot szeretnénk el- 
helyezni, amit kiválasztva a felhasználó a historyban egy oldal- 
lal visszalép, a következőt kell írnunk: 

£Xdo label-"Vissza" typez"prev"2 

£prev/2 
€/do2 


Egy sor közben definiált hiperlink (pl. 
Za href-"index.wml"2Klikkk/a2 
egyenrangú az alábbiakkal: 


Xxdo label-"Klikk" typez"unknown"2 
£go href-"index.wml"/2 


A cdo2 elemet a kártyán belül bárhol elhelyezhetjük, de a böngészőn 
múlik, hogy hogyan jeleníti azt meg. Az ca2 elemmel meghatáro- 
zott hivatkozás a szövegben ott jelenik meg, ahol azt definiáltuk. 


Események 
A cdo2-hoz hasonló elem az £onevent2. Az Conevent? elemben 
definiált műveletet (£noop/2, £refresh/2, £prev/2 vagy £g02) 
azonban nem a felhasználói beavatkozás, hanem egy bizonyos 
esemény bekövetkezte kezdeményezi. Négy ilyen esemény léte- 
zik, ebből az első hármat card vagy template szinten definiálhat- 
juk, az utolsót pedig az coptions elem tartalmazhatja: 
8 ontimer - az időzítő lejárt (lásd később a £timer: elem 
ismertetésénél) 
8 onenterforward - a felhasználó továbblép, például követ egy 
hivatkozást, vagy egy £g02 parancs hajtódott végre 
onenterbackward - a felhasználó visszalép, például a his- 
toryból navigál, vagy egy £prev/2 parancs hajtódott végre 
8 onpick- ez az esemény egy option? elemben hajtódhat vég- 
re, azt jelzi, hogy a felhasználó a szülő cselect2 adatbevite- 
li mezőben az adott opciót választotta (ez azt is jelenti egyben, 
hogy az £option? elem tartalmazhát £onevent? elemet is). 
A fenti eseményneveket az érintett Conevent? elem type attri- 
bútumaként adhatjuk meg. Ha a böngésző olyan £onevent? ele- 
met talál, amelynek típusa nem szabványos, vagy nem illeszke- 
dik a szülőelemhez, az eseménykezelőt figyelmen kívül hagyja. 


A ccard? elem attribútumai 
A ccard? elem fontosabb attribútumai az alábbiak: 
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A 


"b title a kártya címe (a böngészők általában 

az oldal tetején, külön sorban jelenítik meg) 

0 newcontext - ha értéke , true", akkor a 
böngésző a card megjelenítése előtt törli a his- 
tory-t és az oldalhoz esetleg tárolt értékeket. Az 
alapértelmezés , false" 

"0 ordered - ha értéke , true", a card-on található beviteli mezők 
megjelenítési (és kitöltési) sorrendje kötött. Akkor használ- 
hatjuk, ha olyan kérdőívet töltünk ki, aminek minden mező- 
jét kötelezően meg kell adni. 

B onenterforward, onenterbackward, ontimer - egyszerű- 
sített eseménykezelő rutinok; ha ezeknek az attribútumok- 
nak átadjuk az adott esemény bekövetkeztekor betöltendő 
oldalak URL-jét, nem kell a kártyán belül definiálnunk a 
megfelelő £onevent? elemeket. 


A Stemplate? elem 

A WML deck a £card2-okon kívül még template? elemet is tar- 
talmazhat. Ezt az elemet arra használhatjuk, hogy benne olyan pa- 
rancsokat, eseményeket definiáljunk, amelyek a deck összes kártyá- 
jában érvényesek lesznek (tehát mintha az összesben egyenként lét- 
rehoztuk volna). Minden £do2 elemnek adhatunk saját nevet (erre 
való a , name" attribútumuk) . Ha egy £card? egy, a template-ben 
definiált cdo2-val megegyező nevű £do? elemet tartalmaz, a kár- 
tya szintjén definiált parancs felülbírálja a közös definíciót. Ha a 
kártyában található £do2 parancs a £noop/2 műveletet tartal- 
mazza, az adott parancs az adott kártya megjelenítésekor nem lesz 
elérhető. A következő példában template szinten létrehozunk egy 
parancsot, amit a card1-ben meghagyunk, a card2-ben felüldefiniá- 
lunk, a card3-ban pedig egyszerűen eltüntetünk: 


£wm12 
XKtemplate2 
£XKdo typez"options" name-"dol" label-"klikk"2 
£go href-"index.wml"/2 
£/do2 
£/template2 
£Kcard id-"cardh"? 
£p2Itt örököljük az eredetit. ..€C/p2 
£/card2 
£Kcard id-"carde"? 
£p2Itt egészen mást csinálc/p2 
£Xdo types"options" name-"dol" label-"klikk"2 
£prev/2 
£/do2 
£/card2 
card id-"card3"2 
£poItt nincs is ilyen parancs!C/p2 
£XKdo typez"options" name-"dol" label-"klikk"2 
£x£noop/2 
£/do2 
£/card2 
£/wm1i2 


Változók a kódban 

A WML kódban szinte bárhol használhatunk változókat, ahol 
egyébként valamilyen szöveges értéket adhatnánk meg. Ez lehet 
egy elem tartalma, vagy pl. egy attribútum értéke is. Több olyan 
WML elem van (főképp adatbeviteli elemek), amelyek az adato- 
kat automatikusan egy-egy változóban tárolják (a változó neve 
pedig megegyezik az elem name paraméterében megadott név- 
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vel). Amikor a változó értékét fel akarjuk használni, a neve elé 
írt $ jellel hivatkozhatunk rá. A legjobb példa erre valamelyik 
adatbekérésre való kérdőív-elem (szövegmező, rádiógomb, stb.) . 
Amikor ezeknek az elemeknek nevet adunk, egyben létrehozunk 
egy (az elem nevével megegyező nevű) változót is. A kérdőív-e- 
lembe írt adatot mindig az adott változó tartalmazza. A kérdőív 
elküldésekor pedig a gpostfield2 mezőben felhasználjuk az 
adott változók tartalmát. Lássunk egy példát, ami adatot kér be 
két szöveges mezőbe, majd azok tartalmát szabványos HTTP POST 
kéréssel elküldi a kiszolgálónak további feldolgozás érdekében: 


XKwmlxkcard id-"cardl" title-"Teszt"2 
gpoVezetéknév: 
ginput titlez-"Vezetéknév:" typesz"text" namez"nl"/2 
£br/2Keresztnév: 
dginput title-"Keresztnév:" type-"text" namez"n2"/2 
£/p2 
£Xdo typez"accept" label-"Rendben"2 

£go method-"post" href-"index.wml"2 

gpostfield name-z"namel" value-"$ni"/2 

gpostfield namez"name2" valuez"$n2e"/2 

£/go2 
£/do2 
£/card2k/wml2 


Vegyük észre, hogy nincs a HTML-hez hasonló cform? elem, a 
mezőket egyszerűen csak elhelyezzük az oldal kódjában, majd 
ha kell, a megfelelő £g02 művelettel küldjük el az adatokat. A 
változók értékét magában az oldal szöveges kódjában is felhasz- 
nálhatjuk. A korábban már említett crefresh/2 művelet min- 
dig a változók új értékével generálja újra az oldal tartalmát: 


wKwm1pkcard id-"cardl" title-"Teszt"? 
£p? rj ide valamit: 
£Kinput titles"Valami:" type-"text" namez"vl"/2 
£br/2Ezt írtad:€br/2$v1S/p2 
£XKdo type-"refresh" label-"Rendben"2 
Krefresh/2 
£/do2 
£/card2k/wml2 


Időzítés - a ctimer? elem ú 
Minden £card? tartalmazhat egy £timer? elemet. Ez az elem 
egy időzítőt indít el, amikor a card megjelenik, majd kiváltja az 
,ontimer" eseményt, amikor az időzítés lejárt. 


gcard2 
gonevent type-"ontimer"2 
£go href-"next.wml"/2 
£/onevent2 
€Ktimer name-"tl" value-"100"/2 
£xp2Hello World! c/p2 
£/card2 


A fenti példa körülbelül tíz másodperc múlva továbblép a 

next.wml lapra. A ctimer? elem főbb attribútumai: 

"9 name - a változó neve, amiben az időzítő-számláló található. 
Értéke folyamatosan csökken. Ezt az attribútumot nem kö- 
telező megadni. 

0 value - az időzítés értéke, kb. 1/10 másodpercben 


tün. DA: 


Kérdőívelemek, adatbeviteli mezők 

Ha már az adatbevitelnél tartottunk, lássuk, milyen adatbeviteli ele- 

mek találhatók a WML-ben. A legkézenfekvőbb a tiszta szöveges ada- 

tok bevitelére való Cinput? elem. A legfontosabb attribútumok: 

"8 name - az elem és az értékét tartalmazó változó neve 

"0 title - a mező címe (ezt az attribútumot a böngésző fel- 
használhatja a beviteli mező megjelenítéséhez, pl. az oldal 
fejlécében) 

"b type - ,text" (szöveg) vagy ,password" (jelszó) 

"8 value - a mező alapértelmezett, előre megjelenő értéke (ha a 

Name" attribútumban meghatározott változó még nem tar- 

talmaz más értéket) 

format - beviteli maszk (formátumkódok: A - nagyalakú 

nem szám karakter, a -— kisalakú nem szám karakter, N — szám- 

jegy, X - nagyalakú karakter vagy szám, x - kisalakú karakter 

vagy szám, M és m - bármilyen karakter, " - akárhány darab 

adott karakter (" után valamelyik korábban említett formátum- 

kód állhat, pl. "a z akárhány csupa kisalakú karakter), 1-9 - mint 

a csillag, csak adott számú jelre érvényes (pl. 2a - két kisbetű), 

lc - a I jel után álló karakter megjelenik a beviteli mezőben) 

0 emptyok  - ,true" értéke esetén a mezőt kitöltetlenül lehet 
hagyni (ha nem adjuk meg, alapértelmezés a , false") 

"b size - a mező , szélessége", karakterben 

"b maxlength- a bekérhető adat maximális hosszúsága, karakter- 
ben (ha nem adjuk meg, elvileg végtelen, gyakorlatilag a bön- 
gészőn múlik, mennyit fogad el) 

A másik adatbeviteli elem a feleletválasztós típus. WML-ben ezt 

a cselect? és , gyermekelemei" valósítják meg. Lássunk először 

egy egyszerű feleletválasztós példát: 


s 


title-"Válassz!"2 
goption title-"s1" valuez"s1l"2Első£/option2 
£goption title-z"s2" valuez"s2"o2MásodikkK/option2 


select name-"vl" 


goption titlez"s3" 
€/select2 


value-"s3"2Harmadikk/option2 


A cselect? elem főbb attribútumai: 

"B name - az elem és a választott opció értékét tartalmazó vál- 
tozó neve 

"b iname - egy változó neve, ahova a kiválasztott opció sorszá- 
ma kerül (0 - nincs kiválasztott érték) 

"0 title - a mező címe 

"B multiple ha értéke , true", akkor egynél több értéket is ki 
lehet választani (ha nem adjuk meg, az alapértelmezés , false") 

"8 value - az elem alapértelmezett értéke (ha a name attri- 
bútumban meghatározott változó még nem tartalmaz más ér- 
téket) 

"8 ivalue- az elem alapértelmezében kiválasztott opciójának sor- 
száma (ha az iname attribútumban meghatározott változó 
még nem tartalmaz más értéket) 

Amikor több értéket is kiválaszthatunk, az egyes értékek a változók- 

ba egymás után, pontosvesszővel kerülnek bele (és így is kell őket elő- 

re megadni, ha szükség lenne rá). Mint a példában látható, a 

Sselect? elem opciókat tartalmaz(hat), minden egyes sort egy- 

egy Soption? elem személyesít meg. Az elem tartalma (a nyitó és 

záró tagok közötti rész) jelenik meg a felhasználónak. Az elem fonto- 
sabb attribútumai pedig: 

"0 title - az opció ,neve" 

"B value az opció értéke 

"8 onpick - ha ennek az attribútumnak értéket adunk (egy URL-t) , 
akkor az opció választásakor a böngésző azonnal a 
megadott címre ugrik 
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Az elemcsalád harmadik, új tagja az Soptgroup2 a 


vs 


eíítáatzatátáátae 


elem. Ennek az elemnek mindössze annyi a célja, 
hogy a könnyebb kiválasztás érdekében csoportosít- 
hassuk a lehetőségeket. 
€Kselect name-"v2" title-"Hányadik legyen?"2 
goptgroup title-"Egytől-Háromig"? 
goption title-"1" value-"1"2Első£/option2 
fgoption title-"2" value-"2"xMásodikk/option2 
£goption title-"3" value-"3"2Harmadikk/option2 
£x/optgroup2 
goptgroup title-"Négytől-Hatig"2 
£goption title-"4" valuez"4"52NegyedikC/option2 
goption title-"5" value-"5"2 tödikk/option2 
£goption title-"b" value-"h"2Hatodikk/option2 
£x/optgroup? 
£/select2 


Az goptgroup? elem title attribútuma határozza meg, hogy 
mi legyen a csoport neve, de ennek a megjelenítésen kívül más 
szerepe nincsen. A böngésző eldöntheti, hogy felhasználja-e ezt 
az információt, vagy sem. Egyes böngészők esetén először a két 
csoport közül kell választanunk, majd azok tartalmából, mások 
pedig egyszerűen sorban megjelenítik az összes opciót. 


Képek 

A wapos eszközök képesek minimális gra- 
fikai elemek megjelenítésére is. Ehhez 
speciális, kétszínű fájlformátumot, a 
.wbmp-t (MIME típus: image/vnd.wap.wbmp) 
használják, bár az újabb eszközök már 
képesek a .gif, sőt, animált .gif fájlok 
megjelenítésére is. A .wbmp formátum 
létrehozásához több eszköz is található 
az Interneten, egyet az [5] címről le- 
tölthető Nokia Mobile Internet Toolkit is 
tartalmaz. Figyelem! A képek a WML 
deck-től külön töltődnek le, de a koráb- 
ban már említett méretkorlátozás (álta- 
lában 1.3 kbájt) a képekre is igaz! 

A képek beillesztésére az cimg/? elemet 
használhatjuk. Az elem kötelezően meg- 
adandó attribútumai pedig az alábbiak: 
B sre - a képfájl URL-je 

"0 alt - alternatív szöveg a kép helyett 


Guen 








£card id-"c1l" title-"Garfield"2Cp alignz"center"? 
£ximg srcs"garf7?5.wbmp" alt-"Lusta macska"/2 


£/p2S/card 


Fülöp Miklós 
mick netacademia.net 





Pia Let T-IHETZA ÉLNI S 
[1] http://www.wapfoi 
[2] http://www.wapforur org 

[3] http://www.ayg.com/images/wml ref.pdf 
[4] http: //developer.openwave.com/ 

[51 http;, ///www.forum.nokia.com/ 
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.NET Akadémia 


(I. rész) 


Új év, új sorozat. Elérkezett az idő itt Magyarországon is, hogy belevágjunk egy 

ki tudja milyen hosszú ideig tartó kalandba, és feltérképezzük a .NET szövevényes világát. A 
.NET-ről, mint fejlesztési háttérről már írtam egy bevezetőt a Tech.net 2001. júniusi számban. 
Aki még egyáltalán nem találkozott a .NET-el, annak ajánlom a cikket elolvasásra, 

mert az abban leírtak ismeretét már alapul veszem ebben a részben. 


: NET alapok 

Kezdetben valák a sík API-k. Egy nagy, ömlesztett massza, egy 
nagy függvénykészlet, amely segítségével kiaknázhattuk a Win- 
dows szolgáltatásait. Bajlódtunk kezelőszámokkal (handler) , bo- 
nyolult struktúrákkal. Furmányos neveket adtak a Windows API 
függvényeknek, hogy egyértelmű legyen miről beszélgetünk, szó 
nem volt névterekről vagy bármi egyéb kategorizálásról. 

Az MFC, a VB Runtime, és minden nyelv saját könyvtárai próbál- 
ták elfedni ezt az alacsony szintű API-t, és lehetőleg objektum- 
orientált módon összefogni a funkcionalitásokat. De a háttér- 
ben mindig ott lapult a Windows API. 

Nincs ez másként a .NET-ben sem. Ha megnézzük a Windows-ra 
írt .NET keretrendszer osztálykönyvtárát, akkor a legvégső ope- 
rációs rendszer szolgáltatások igénybevételekor ott lapulnak a 
jó öreg API függvények. Azonban igen jelentős különbségek 
vannak például a VB6 Runtime és a .NET mögötti osztálykönyv- 
tárban. A legjelentősebb különbség oka az a tény, hogy a .NET- 
es programokat, így az osztálykönyvtár szolgáltatásait is már 
nem közvetlenül az operációs rendszer futtatja, hanem a .NET 
saját futtató rendszere. A .NET futtató rendszer viszont csak 
egyféle formátumú programokat képes futtatni, amelyek Micro- 
soft Intermediate Language (MSIL) nyelvre vannak lefordítva. 
Azaz nem platformfüggő, például x86-os processzorra lefordí- 
tott kódot futtat a .NET futtató, hanem IL-t. Az IL-t nem folya- 
matosan értelmezi és futtatja, mint hajdanán a Basic interpre- 
ter, vagy a Java virtuális gép, hanem igény esetén, egy-egy me- 
tódus meghívásakor lefordítja a metódus törzsét a platformnak 
megfelelő gépikódra, és azt futtatja a processzor. Tehát végül is 
gépikódot futtatunk, csak a fordítás IL-ről gépikódra röptében 
történik meg, egy-egy függvény meghívásakor. Ennek a látszó- 
lag időpazarló, lassú eljárásnak számtalan előnye lesz, de talán 
a legfontosabb, hogy a futtató rendszer pontosan tudja mit 
szándékozik tenni egy program. Nemcsak reménykedünk abban, 
hogy egy letöltött .NET komponens nem kezd-e el matatni a sa- 
ját dokumentumaink között, hanem teljes bizonyossággal tud- 
hatjuk, hogy akar-e ilyet tenni (és persze előírhatjuk, hogy mit 
tehet és mit nem). Gépikódú programok esetén nagyon nehéz 
lenne a futtatónak megtudni, pontosan mit is akar egy program 
tenni, mert a gépikódra kioptimalizált kódban elmosódik a 
programozó eredeti szándéka. A .NET-es fordítók által generált 
IL szándékosan olyan szószátyár, hogy a futtató rendszer egzak- 
tul tudja szabályozni, hogy milyen erőforrásokat enged a kód 
közelébe, és melyeket zár el tőle, és ezt be is tudja tartatni. 
Pont az ellenőrzöttsége miatt hívjuk a .NET-es fordítók által ge- 
nerált IL kódot menedzselt kódnak. S ki a menedzser? Nos, ő a 
Common Language Runtime, akit barátságosan csak CLR-ként 
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szoktunk emlegetni. ő fogja osztani az összes áldást, amiről a 
cikksorozat szólni fog. 


A .NET mindenre jó? 

Sokan azt gondolják, hogy a .NET miatt megszűnik a hagyomá- 
nyos programozás létjogosultsága, azaz senki nem fog már nem 
menedzselt kódot írni (persze beszéljünk csak a Windows progra- 
mozókról) . És mi lesz az eszközmeghajtók íróival? Mi lesz azokkal, 
akik nagyon gyors, alacsony szintű, kis tárigényű komponenseket 
akarnak írni? ők nem fogják egyhamar kidobni például az ATL-t 
(Active Template Library). Aki szeretne generikusan, template-ek 
segítségével programozni, vagy nem tud meglenni többszörös 
öröklődés nélkül, az jobb, ha marad a nem menedzselt világban. 
Mindig is lesznek olyan feladatok, amelyek nem valósíthatók 
meg menedzselt kódban. Egyre több mindenre lesz jó, de pél- 
dául magát a .NET futtató rendszert is meg kellett írni valaki- 
nek, és ugyebár azt nehéz lett volna .NET-ben megírni. 

A CLR a benne futó programok számára maga a Mátrix. Egy szi- 
mulált világ, ahol ízletesek az ételek, az emberek jól néznek ki, 
de vannak kötöttségek, számítógépek határozzák meg mit tehe- 
tünk és mit nem. Cserébe kapunk egy nagycsomó szolgáltatást, 
így sokkal gyorsabban meg tudunk valósítani sokféle funkciona- 
litást. A másik, a való világban szinte mindent megtehetünk (na, 
jó, a fizika még működik) , nem befolyásolnak a gépek, szabadok 
vagyunk. Cserébe viszont egy sokkal kellemetlenebb környezet- 
ben kell programoznunk. Ez a jelen, azaz a nem menedzselt kód. 
Biztos lesz sok olyan macsó programozó, aki nem hajlandó ma- 
gát alávetni a CLR rendőrállam intézkedéseinek, és ő soha az 
életben nem fog menedzselt kódot írni, mert ő nem szereti, ha 
megkötik a kezét. Tényleg? Akkor ideje visszatérni a DOS-os vi- 
lágba, ott tényleg nem kötötték meg a kezünket. Ha akartuk, 
közvetlenül belenyúlhattunk az összes hardverjellemzőbe. Ha 
úgy tetszett akár szektorszinten írhattunk a merevlemezre. Sen- 
ki nem szólt, hogy hóha, ez a partíciós tábla. 

Aki valamilyen mai operációs rendszer alá dolgozik, annak el 
kell fogadni, hogy meg van kötve a keze. Azért, mert nem csak 
az ő programja fut egyedül a számítógépen, így védeni kell 
egymástól és sokszor önmaguktól is a programokat. Erre való az 
operációs rendszer, és aki nemmenedzselt kódot ír, az is szem- 
beütközik ezzel. Aki tényleg macsó akar lenni, az írjon 
eszközmeghajtót kernelmódban. 

Amit látnunk kell, hogy a .NET egy újabb absztrakciós réteg a fi- 
zikai vas, a számítógép hardvere, és a programjaink között. Az 
oprendszer az első réteg, arra építették fel a CLR-t, ami egy újabb 
réteg. Az indirekció ára nyilvánvalóan némi teljesítménycsökke- 
nés, cserébe a futtató rendszer jobban kordában tudja tartani a 
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programokat, ami például megbízhatatlan, internetről letöltött 
vezérlők és programok (vírusok) esetén rendkívül fontos dolog. 
És még van egy óriási előnye. Mi akadályoz meg valakit abban, 
hogy megírja a CLR-t más operációs rendszerre? Ha a CLR való- 
ban annyira el tudja szigetelni a programunkat a hardvertől, ak- 
kor semmi akadálya, hogy az IL formátumú programunk más 
operációs rendszer alatt, sőt, akár más architektúrán fusson. 
Csak egy feltétele van ennek: a CLR minden szolgáltatása meg 
legyen írva, amit a programunk igényel a futtatandó platfor- 
mon. A Microsoft már jó ideje írja a Linux-os CLR-t... 


Csapjunk bele! 

Ennyi bevezető után térjünk rá konkrét témákra. Fejleszteni sze- 
retnék .NET-es, menedzselt programokat. Mire lesz szükségem? 

A legfontosabb alap a .NET Framework SDK. Ezt egy ingyenesen le- 
tölthető telepítőprogram [1] rakja fel. Ezután rögtön elindulha- 
tunk a .NET felfedezésére. Első körben nem érdemes felrakni a 
Visual Studio.NET-et, jobb látni, mi van ténylegesen a .NET mögött. 
A VS sokmindent trükkösen elfed illetve levarázsol helyettünk, ami 
nagyon jól jön majd akkor, amikor már értjük, miért pont azt a kó- 
dot varázsolta be, amit. De addig is inkább használjunk parancsso- 
ri eszközöket és egy számunkra kényelmes szövegszerkesztőt. Akár 
notepad is lehet, bár nekem a fapad nem kényelmes. 

A Framework SDK telepítése után a .NET rendszerállományai javarészt 
a CAWINNTMWicrosoft.NETWrameworktwv1.0.2914 mappába kerülnek 
bele. A v1.0.2914 kiadásonként változik, ez a Beta2 verziószáma (a 
cikk megjelenésekor már lesz végleges termék is). 

Ebben a könyvárban van egy csc.exe, vbc.exe és jsc.exe. Ezek a 
CH, VB.NET és JScript.NET fordítók. Mivel ezeket és a többi se- 
gédprogramot is gyakran fogjuk használni, érdemes a mappát 
könyvtárból könnyen futtathatjuk őket. 

A cikksorozatban szinte mindig Ctt nyelven fogom közölni a pél- 
daprogramokat. Ahol érdekes, ott megemlítem a VB.NET-es vál- 
tozatot is, de általában a kulcsszavak kicserélésével könnyen 
átírhatjuk egyik nyelvről a másikra a programokat. 

Kezdjük a szokásos Helló világ program megírásával. 


class ElsobotnetesProgi 


( 
public static void Main() 


( 
System.Console.WriteLine("Helló világ! (1)"); 


) 


Írjuk be egy szövegfájlba és mentsük el hello1.cs néven. Nyis- 
sunk egy konzolablakot, és fordítsuk le a programunkat! 


csc hellol.cs 
A csc.exe a Ct fordító, ami bemenetül egy CH forráskódot tar- 


talmazó fájlt vár, és készít egy ugyanolyan nevű .exe-t. 
Futtassuk le a hello1.exe-t! 





:Mmetlbcsc hellol.cs 
iicrosoft (R) Visual CH Compiler Version 7.00.9254 ICLR version vl.0.29147 


opyright (C) Microsoft Corp 2000-2801. ALl rights reserved. 


: metbbhellol exe 
lellő világ! (1) 


: met 





( er working with 


windows / 


Ez igen! Járjuk körbe a forráskódot! 

Ami elsőre szembetűnő, hogy van más nyelvekből 

megszokott main függvény, ahol a program futása 

kezdődik, csakhogy ez egy osztály metódusaként van 
deklarálva. Ennek oka, hogy a .NET-ben nincsenek globális 
függvények, márpedig a main egy ilyen függvény szokott lenni. A 
.NET-ben majd osztályokat (class) és struktúrákat (struct) fogunk 
írni, és azok metódusait - de sohasem globális függvényeket. 
Különösen C programozóknak furcsa lehet, hogy a System.Con- 
sole.WriteLine metódus használatához nem kellett semmilyen 
header fájlt beinklúdolni a forrásba, és fordításkor sem kellett 
megadni annak a kódkönyvtárnak a nevét, ahonnan a metódus 
kódját kiszedné a fordító. Nos, a fenti metódus egy központi 
helyre beregisztrált komponens metódusát hívja meg, amelyet a 
név alapján magától megtalál a fordító. Saját kódkönyvtáraink- 
nál segíteni kell neki, de erről majd még értekezünk a kompo- 
nensek tárgyalásakor. 

Az IL-re lefordult hello1.exe egy modul lett. A modul az egy al- 
kalmazás vagy egy kódkönyvtár (általában .exe és .dil kiterjesz- 
téssel). Egy assembly egy vagy több modul összessége. Egy 
assembly minden modulja tudja, hogy kik a társai, ez a modu- 
lok elején található manifest információs blokkban tárolódik. Az 
assembly lesz majd a verziózás és a telepítés egysége, máskép- 
pen fogalmazva hiába áll egy assembly fizikailag több modulból, 
logikailag egy egységnek tekintendők. Felfogható egyfajta logi- 
kai dll-nek is. Azaz a hello1 egy olyan assembly, ami egy mo- 
dulból áll, és ez a hello1.exe. 

A .NET futtató a Main metódust hívja meg a programunk elindí- 
tásához. Public, azaz nyilvános az ő láthatósági jelzése, így a 
futtató el tudja érni. Alapban, Ct-ban minden osztálylakó pri- 
vate, azaz saját lenne, így még a futtató sem tudná meghívni a 
Main-ünket. A static kulcsszó pedig azt jelenti, hogy az osztá- 
lyunkból (ElsoDotnetesProgi) nem kell létrehozni példányt a me- 
tódus meghívásához, közvetlenül is megtehetjük azt. 

Figyeljük meg, hogy a Main nagybetűvel van írva. A Ct kis-nagy- 
betű érzékeny, ami nagy érvágás tud lenni a VB programozóknak, 
de aki ezt nem tudja megemészteni, még mindig ott a VB.NET. 
Az érdemi kiíratást a WriteLine metódus végzi, ami egy statikus 
metódusa a Console osztálynak, ami pedig a System névtérben 
lakik. A .NET-ben az osztályokat névterekbe rendezhetjük, így 
egy-egy funkcionalitást megvalósító, logikailag kapcsolódó osz- 
tályokat összefoghatjuk. Például a System.IO névtérben van az 
összes fájlkezeléssel kapcsolatos osztály. Vagy a System.XML- 
ben az XML dokumentumok kezelését végző osztályok. A System 
osztály egy vegyesfelvágott, ebben vannak deklarálva az alaptí- 
pusok (int, string, ...), és sok, a típusokon műveletet végző osz- 
tály. Nem Helló világ méretű programok esetén nagyon hasznos 
a saját osztályainkat is megfelelő, leíró jellegű névterekbe te- 
relgetni. Tipikus a Cégnév.Funkció.Alfunkció névtérhasználat, 
például NetAcademia.Web.Pages. 

Habár a System.Console.WriteLine még nem túl hosszú ahhoz, hogy 
begépeljük, azért a System.Runtime.InteropServices.Custom- 
Marshalers. EnumerableToDispatchMarshaler.MarshalManagedToNati- 
ve ötödik begépelésekor lehet, hogy a pokolba kívánnánk a névtér 
kitalálóit. A gépelések csökkentésére a használni kívánt névtereket 
előre megjelölhetjük a programunk elején, így elég csak az osztá- 
lyok neveire hivatkozni. Erre a using kulcsszó való"(VB: Imports). 


using System; 
class ElsobDotnetesProgi 
ú 


public static void Main() 
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Console.WriteLine( "Helló világ! (2)"); 
) 


A fordító végignézi az összes, using-okban megadott névteret, 
amikor egy osztályt keres, a példánkban a System névtérben 
meg fogja megtalálni a Console osztályt. 

Általában nem hivatkozunk az osztályokra a teljes nevükkel, ha- 
nem minden használt névtérre felveszünk egy álnevet a using 
segítségével. Fontos, hogy értsük, hogy az esetleg felesleges 
using-ok miatt nem lesz nagyobb a lefordult program, ez csak 
egy egyszerű gépelési segítség nekünk. 


A színfalak mögött 

Nézzük meg mivé fordult le a hello1.cs! Lett belőle egy 3 kBájtos 
.exe. Ez nem rossz. Hogyan nézhetnénk bele? Van egy ildasm.exe 
nevű IL visszafejtő programunk, szintén települ az SDK-val. Ez a 
c:ANProgram  FilesMMicrosoft.NetWrameworkSDKYWBin mappában 
rejtőzködik, újabb könyvtár aminek a path-ban a helye. 

Nyíljon hát ki a nagyvilág! 


ildasm hellol.exe 
Előugrik az ILdasm, benne a hello1.exe-nk. 


BZ laz) 


f hello1.exe - ILDASM 
Elle View Help 





a-v THE ] 
b MANIFEST 
s. HE ElsoDotnetesProgi 
b .class private auto ansi beforefieldinit 
" ER .ctor : voidí() ] 


EA. Main : voidí) 
ha 


Láthatjuk a saját osztályunkat, annak konstruktorát (.ctor, at- 
tól, hogy nem írtunk még generálódott), és a Main metódusun- 
kat. A MANIFEST a már említett bevezető információ, ami a 
hello1 assembly-t írja le: 


assembly extern mscorlib 


K 
.publíckeytoken - (B7 7A 5C 56 19 34 EG 89 ) 
.Wer 1:0:2411:0 


p 
assembly hellot 
K 


7/ -— The Following custom attríbute ís added automatically, do not unconr 
.custom instance void [mscorlib]System.Diagnostícs .Debuggablekttríbute: 


ritha 0x00009004 


4 





Ami nagyon érdekes, hogy rögtön az első sorból látszik, hogy a 
programunk működéséhez szükség lesz az mscorlib nevű assem- 
lesített változatára. A futtató már a manifest felolvasásával le 
tudja ellenőrizni, hogy egyáltalán van-e értelme elkezdeni fut- 
tatni az alkalmazásunkat, minden kódkönyvtár elérhető-e? Ez 


vorkinú vitnk 


windows / 


nem volt jellemző a DLL és COM világban, nem lehetett meg- 
mondani, hogy egy programnak pontosan milyen külső DLL-ekre 
vagy COM komponensekre van szüksége. 

A Main metódusra kettőt kattintva felugrik a metódusunk IL-re 
lefordított kódjának visszafejtett változata. Az első utasítás le- 
nyomja a verembe a kiírandó szöveget tartalmazó bájttömböt 
(Unicode string), míg a második meghívja a kiírató függvényt. 





Í-nethod public hidedysig static void Main() cl managed 


-entrypoint 
4 Code síze 41 (man) 
(naxstack 


ÜL o609: ldstr  hytearray (48 0065 





90 F3 09 20 09 76 00 69 00 // H.6.1.1... 4. 
4 00 20 00 28 00 21 00 29 00) // 1...g.t.2CTI 
zirátetánetstráng 





MLo8es: cali 
179002: ret 
 //end of method ElsobotnetesProgi ::Hain 


void [ascorlíbjsgstes 





Családfakutatás 
Az ILDasm-ben kattintsunk kettőt a háromszöggel jelzett .class 
private auto ansi beforefieldinit feliratra. 


.class private auto ansi beforefieldinit 
ElsobotnetesProgi extends [mscorlib]System.Object 
() // end of class ElsobotnetesProgi 


Látható, hogy az ElsoDotnetesProgi osztályunk az mscorlib-ben 
lakó System.Object osztályból öröklődik. Hogy lehet ez, hisz 
nem jelöltünk ki semmilyen öröklődést? 

Egy nagyon alapvető és fontos tényre bukkantunk rá: .NET-ben 
minden osztály és típus implicit módon a System.Object-ből örök- 
lődik. Mind a saját osztályaink és struktúráink, mind a .NET Class 
Library összes osztálya. Még az olyan primitív típus, mint az inte- 
ger is az Object-ből származik. Ennek mélyenszántó következmé- 
nyei lesznek, amelyekkel a következő részben, a .NET típusok ismer- 
tetésénél részletesen fogunk foglalkozni. Egyenlőre elég annyi, 
hogy a közös ős miatt minden típus elérhető lesz System.Object re- 
ferencián keresztül, és egységesen kezelhető lesz mint egy általá- 
nos Object osztály, másrészt minden objektum támogatni fog né- 
hány olyan alapvető metódust, amit a System.Object-ből örökölt. 


Osztály vigyázz! 

A .NET leggyakoribb típusa a class, amit magyarul osztálynak 
szoktunk fordítani. Ismerkedjünk meg vele! 

Egy osztály nem más, mint egy sablon objektumok létrehozásához, 
amely tartalmazza az objektum adatainak leírását és a rajtuk elvég- 
zendő műveleteket is. Az osztályok egyik legfontosabb feladata elfed- 
ni a mögöttük rejlő adatok fizikai szerkezetét, és így kívülről számunk- 
ra csak az objektumon végezhető műveletek a fontosak és láthatóak. 
Például legyen egy olyan osztályunk, ami számokat képes tárolni 
(kollekció). Hogy ez belül egy láncolt listával vagy egy tömbbel 
van megvalósítva nem tartozik az osztályt használókra. Természe- 
tesen a sebesség és karbantarthatóság szempontjából egyáltalán 
nem mindegy a háttérstruktúra, de ezt ledokumentáljuk a felhasz- 
nálóknak, hogy milyen jellegű igénybevételre melyik módon meg- 
valósított kollekciónkat ajánljuk neki. Kívülről nem szabad látsza- 
nia a tényleges tárolási struktúrának, csak biztosítani kell a mű- 
ködéshez szükséges műveleteket. Hozzáadni új elemet a listához 
(pl. elejéhez, végéhez, adott pozícióra), kitörölni egyet, lekérni 
vagy beállítani egy elem értékét, satöbbi. Ezek mind az objektu- 
mon elvégezhető műveletek voltak, amelyeket a háttéradatoktól 
függő módon, de mindkét esetben meg lehet valósítani. 


class JorgomBorger 


( 
//tagok 


és: 03 c 


A kapcsos zárójelek között fogjuk leírni az osztály által tartal- 
mazott adatokat és az osztályon értelmezett műveleteket (tago- 
kat). Hogyan lesz egy osztályból egy konkrét, élő objektum? A 
new operátor segítségével. 


JorgomBorger j - new JorgomBorger ( ) ; 


A sor végrehajtása után létrejön az osztályunk mintájára egy ob- 
jektum a szemétgyűjtő által karbantartott halmon (heap). A j 
egy objektumreferencia, amin keresztül fogjuk tudni elérni az 
osztály tagjait. Az osztálynév utáni zárójel kötelező C$-ban. 

Az objektumorientált irodalomban egy osztálynak kétféle tagja 
van: adat-tagok vagy mezők (fields) és függvény-tagok vagy metó- 
dusok (methods). A .NET-ben még két tagot hozhatunk létre: jel- 
lemzőket (property) és eseményeket (events). Az utóbbi kettő elég- 
gé egyedi a .NET-ben, más rendszerekben interfészekkel és metó- 
dusokkal szokták szimulálni őket. Mivel a .NET natívan támogatja 
őket, elég sok unalmas programozási munkától kímél meg minket. 


Mezők 

A mezők tárolják az osztály által reprezentált adatokat, máskép- 
pen szólva ezek tárolják az osztály állapotinformációit. Kétféle 
mezőt hozhatunk létre egy osztályon belül. Az egyik minden 
egyes, az osztályból létrehozott objektumpéldányban egyedileg, 
egymástól függetlenül létrejön, ezek a példányonkénti mezők 
(instance fields). Ez az alapértelmezett típus. A másik típus kö- 
zös minden objektumpéldányra, azaz osztályonként mindig csak 
egy van belőle. Ezek a statikus mezők (static fields). 


class JorgomBorger 
( 
int a;  //példányonkénti 


static double b;  //közös 


VB-ben a statikus mezőt a Shared kulcsszóval azonosítjuk, ami 
jobban kifejezi a működését, de az objektumorientált irodalom 
a static kulcsszót favorizálja. 

A mezők tartalma közvetlenül nem tartozik a külvilágra! Ez az osz- 
tály belső működéséhez kell, kifelé ellenőrzött módon, metóduso- 
kon és jellemzőkön keresztül engedjük csak elérni őket. Ez nagyon 
fontos alapelv, mert így ki tudjuk cserélni az osztály teljes belső 
adatszerkezetét anélkül, hogy ebből a külvilág (az osztályfelhasz- 
náló programok) bármit is észrevennének. Ez a karbantarthatóság 
és a bővíthetőség miatt nagyon fontos 00P alapelv. 


Metódusok 

A metódusok az osztályon végrehajtható műveleteket írják le. A 
mezőkhöz hasonlóan ezek is lehetnek példányonkénti vagy kö- 
zösek. A példányonkénti metódusok mindig egy bizonyos példá- 
nyon dolgoznak. 


using System; 
class ElsobotnetesProgi 
( 
public static void Main() 
( 
JorgomBorger jbl - new dJorgomBorger ( ) ; 
JorgomBorger jb2; 
jb2 - new JorgomBorger ( ) ; 
jb2.LegyenAzA(8) ; 


Console.WriteLine("Ez egyik a: (0) ", 


working vith 


windows / 


jb1.NaMiAzA-( ) ) ; 
Console.WriteLine("A másik a: (0) ", 

jb2.NamMiAzA-( ) ) ; 
Console.WriteLine(" H-H 

JorgomBorger . NaMiAB( ) ) ; 


class JorgomBorger 
( 
int a - 4; — //példányonkénti mező 
static double b - 5.57;  //közös mező 
//Példányonkénti metóődusok 
public int NaMiAzA() 
( 
return a; 
b 
public void LegyenAzA(int x) 


7/Egy statikus (közös) metódus 
public static double NaMiAB() 
( 


return b; 


Kimenet: 


Ez egyik a: 4 
A másik a: 8 
be 18057 


Létrehoztunk két JorgomBorger objektumot. A másodiknak meg- 
hívtuk a LegyenAzA() metódusát, paraméterül 8-at átadva. A me- 
tódus beállítja a példányonkénti , a" változó tartalmát a paramé- 
terül kapott értékre. A NaMiAzA() meghívásával kiíratjuk mindkét 
példány ,a" nevű mezőjének értékét. Láthatjuk, hogy a két ,a" 
különböző, objektumpéldányonként függetlenül léteznek. 

Ha létrehozunk egymillió osztálypéldányt, akkor a példányszin- 
tű metódusokat alkotó kódok egymilliószor fognak létrejönni a 
memóriában? Ha így lenne, akkor ki sem alakult volna az objek- 
tumorientált programozás. Természetesen csak a példányonkén- 
ti mezők tárolásához szükséges memóriaterületet kell lefoglalni 
egymilliószor, a metódusok kódjai csak egyszer jönnek létre a 
memóriában. Viszont, hogy egy ilyen ,levegőben lógó" metódus 
tudja, hogy mely adatokkal kell neki foglalkozni, kap egy refe- 
renciát (pointert) egy tényleges osztály adataira. Ezt nem lát- 
juk, de a fordító minden példányonkénti metódusnak átadja ezt 
paraméterül a sajátjaink mellett. 

Egy metódusban elérhetjük ezt a saját osztályra mutató referen- 
ciát a this kulcsszóval. Például ha az előbbi példában a 
LegyenAzA() metódus paraméterét ,a"-nak hívjuk, mint az osz- 
tály mezőjét, akkor a this referenciával explicit jeleznünk kell, 
hogy ennek az osztálynak az ,a" mezőjének adunk értéket. 


public void LegyenAzA(int a) 


( 


this.a — a; 
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A statikus metódusoknak nincs szükségük a this refe- 

.!  renciára, ezért a hívásuk szintakszisa is más mint a 

példányonkénti társaiké, jelezve, hogy az osztályra, és 
nem az egyes példányokra vonatkoznak. 


JorgomBorger . NaMiAB( ) 


CH programozók talán furcsán néznek az előző sorra, miért nem :: 
(kettőspontok) választják el az osztály nevét a metódus nevétől? Cit- 
ban minden esetben pontot kell használni, a C---beli -2 helyett is. 
Bár a .NET-ben nincsenek globális függvények és változók, sta- 
tikus mezőkkel és statikus metódusokkal valami hasonlót érhe- 
tünk el, csak mindig ki kell írni az osztály nevét, illetve be kell 
csomagolni egy osztályba a függvényeket és a változókat. 

Mind a metódusok, mind a mezők alapértelmezésben nem elér- 
hetőek az osztály felhasználó programok számára. Ez is az ada- 
tok egységbezárását, elrejtését kívánja elősegíteni. A nagyvilág 
számára is érdekes metódusokat (esetleg mezőket) a public 
kulcsszóval tudjuk láthatóvá tenni. Az összes többi csak az osz- 


tály metódusai számára látható, kívülről nem érhető el, erre 
figyelmezet a fordító. Ez a private elérhetőség. További elérhe- 
tőségi kulcsszavak is vannak. 

A protected kulcsszóval megjelölt tagok kívülről nem látszanak, 
de az osztályon belülről és az osztályból leszármazott osztály 
metódusai elérhetik őket. Az internal kulcsszóval jelölt tagok 
pedig csak ugyanabból az assembly-ből érhetők el. 


Zárszó 

A következő részben megnézzük az osztályok további jellemzőit, 
valamint áttekintjük a .NET további alaptípusait és a rajtuk ér- 
telmezhető műveleteket. Egyet már részben láttunk ebben a 
részben is: az osztályt. Legközelebb sorra kerülnek a primitív tí- 
pusok, a System.Object részletesen, valamint az érték és refe- 
rencia típusok pontos megértése és a közöttük lehetséges kon- 
verzió, a boxing megismerése. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.NET 
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Araink a 2596-os AFA-t nem tartalmazzák! Az árváltozás jogát fenntartjuk! 


Jdüde. Di. LECT1.Net 


XMLgessünk 


(IX. rész) 


Az előző részben láttuk, hogyan kell használni az XmIReader és az XmlWriter 
osztályokat. Gyorsak, de eléggé alacsonyszintű interfészeket adnak a kezünkbe. 
Most megnézzük azokat a technológiákat, amelyek rájuk épülnek, és a segítsé- 
gükkel így jóval fejlettebb módon is tudunk xml dokumentumokat manipulálni. 
A főszereplők a DOM, az XSLT és az XPath lesznek. 


DOM.NET 

A legelterjedtebben használt xml feldolgozó megközelítés a 
World Wide Web konzorcium által ajánlott XML Document Object 
Model (DOM). A DOM nem más, mint xml dokumentumok leképe- 
zése egy memóriabeli fára, amelyen keresztül bejárhatjuk és mó- 
dosíthatjuk a dokumentumok tartalmát, majd visszamenthetjük a 
változtatásokat. A memóriabeli leképezés előny a dokumentum 
tetszőleges bejárása és módosítása során, viszont hátrány a do- 
kumentum méretével arányos memória felhasználás miatt. 

A .NET osztálykönyvtárban az XML DOM-ot a System.Xml.XmIDo- 
cument osztályban valósították meg. Dokumentumok betöltése- 
kor az XmlReader-re épít, elmentéskor pedig az XmlWriter-re. Mi- 
vel az előző részben láttuk, hogy mindkét osztály csak egy váz 
(absztrakt alaposztály) konkrét író és olvasó osztályok megvaló- 
sításához, ezért az XmlIDocument képes bármilyen XmlReader 
vagy XmlWriter megvalósítás adatainak kezelésére, ami - mint 
látni fogjuk - igen érdekes és hasznos együttműködésre ad lehe- 
tőséget egyéb adatforrásokkal: például relációs adatbázisokkal. 
A .NET-es DOM osztályhierarchia az alábbi ábrán látható. 
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6 A .NET-es DOM osztályhierarchia 





Honnan lehet ezt az információt kinyerni (a dokumentáción kí- 
vül)? Az internetről letölthető egy hasznos kis program, aminek 
.NET Reflector [1] a neve. Nagyon hasonlít a Visual Studio.NET 
Object Browser-éhez, csak ingyen van, okosabb, és nem foglal 
el annyi memóriát. A segítségével megnézhetjük, hogy ponto- 
san mi is található egy-egy assembly belsejében, azaz milyen tí- 
pusok, azokon belül milyen metódusok, mezők, interfészek, 
satöbbi vannak implementálva. A private tagok is látszanak, mi- 
vel az ő leírásaik is benne vannak az assembly-kben (metaada- 
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tok formájában), és program által használt Reflection nevű 
technológián keresztül könnyedén láthatóak. 


Ede GT gel AS - [OI x1! 


File View Language Tools Help 











LD System.Messaging ! 
CS System.Runtime.Remoting ! 
x e ömszay ] 











e System.Security 
nm e System.ServiceProcess 
EZ System. web 
1 e System.Web.RegularExpressions 
ge System.Web.Services 
-KZ System. Windows.Forms 
5-(0 System.Xmi ! 
E-W system.xmi.dil ! 
] 40- ] 
-() System 
B-€) System.Xral I 
H-P EntityHandling 
EP) Formatting 
5-3 IHasxXmiNode 
5-2 IXmiLinelnfo ! 
98 NamerTable ! 
EP ReadsState ! 
. —— B-eP Validationtype hd ! 
ÜT Esett] s 





2-1 











class XmiCharacterData 
Namespace: System.Xml 


z1 


5 A .NET Reflector minden részletet megmutat az assemblykből 


Könyvvel vannak jelölve az assembly-k, és azokat kibontva lát- 
hatóak az őket tartalmazó fizikai fájlok, a bennük lakó névterek, 
és a névtereken belül a típusok. 

A következő képen nézzük meg az XmlNode környékét! A 
SubTypes ág alatt jól láthatóak az XmlNode leszármazottjai, il- 
letve az XmlLinkedNode gyermekei. Így állt össze a diagram. 

A Reflector egy igen hasznos eszköz a .NET felderítésekor, mert 
valóban azt látjuk, ami a gépünkön van, nem pedig azt, amit a 
dokumentáció ír. Ez nem azt jelenti, hogy rossz a dokumentá- 
ció, csak azt, hogy így béta fázisban még sok benne a kitöltet- 
len oldal. Egy-egy metódusra kattintva ráadásul a program 
visszafejti a metódus IL kódját, így akár bele is nézhetünk, ho- 
gyan írt meg az MS egy-egy funkcionalitást. 


eDBZ. BA. 
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) bocsmentnariaazor. GetNamespace 


tak W2; 
.1locals (XZPathNamespace V 0) 


L 0000: ldarg.0 

L 0001: ldfld XPathDocumentNavigator.node 

L 0006: ldarg.1 

L 0007: callvirt XxPathNode. GetNamespace s] 
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File éw Language Tools Help 

! ! H.9g xmiNamerTable 
c og Nt 

H-n Supesésési 
--Cu Subtypes 
98 Xrmlaáttribute 
98 XmiDocument 
98 xmiDocumentFragment 
1.0g xXmlEntity 
--0g XmiLinkedNlode 
i 6-0g XmiCharacterData 
98 XmiDeclaration 
98 XmiDocumentType 
98 XmlElement 





















































98 XmlEntityReference 

98 XmiProcessinginstruction 
1.08 Xmilotation 
AppendcChild(XmlNode) : xmiNode 
Clonet) : XxmiNode 





[DefaultMmember] 

public abstract class XmlNode : ICloneable, 

IEnumerable, IXPathNaviagable 

Namespace:  System.XmIl 

GUID: babd5148-cSf4-3a3f- 
acfO-a788fe7d4da5e0 El 





5 A .NET Reflector egészen a metódusok forrásáig lehetővé 
teszi az információbogarászást 


XmiIDocument 

A .NET-es XmIDocument nagyon hasonló a MSXML2.DOMDocument 
COM osztályhoz. A Load() metódus segítségével tölthetünk be egy 
xml dokumentumot a memóriába. Négyféle felüldefiniált változa- 
ta is van a metódusnak, a legegyszerűbb egy fájlnevet vagy URL-t 
vár forrásként. Nem jól formázott vagy elérhetetlen xml forrás ese- 
tén XmlException-t kapunk, amit le kell kezelnünk (try-catch). 


7/ XmiDocumentl.cs 


using System; 
using System.Xml; 
public class XMLDOMTeszt 
( 
public static void Main() 
( 
try 
( 
XmlDocument d - new XmlDocument( ); 
d.Load("a.xml"); 
) 
catch(XmlException ex) 


( 
Console.bWriteLine( 
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"Gáz van a (D. 

"a(z) (1). karakternél." , 

ex.LineNumber, ex.LinePosition); 

Console.WriteLine("A hiba oka:MW( 0) " , 
ex .Message); 


sorban, " § 


) 


A memóriabeli dokumentum bejárásához és módosításához 
megvannak a DOM szabványban definiált szokásos metódusok. 
CreateElement, CreateAttribute, CreateComment, CreateProces- 
singlnstruction, és társaik egy-egy megfelelő XmlNode objek- 
tum létrehozására. Az így létrehozott XmlINode objektumot az- 
tán a kívánt faághoz hozzácsatolhatjuk az AppendcChild, Insert- 
After vagy InsertBefore metódussal. A RemoveAll, RemoveChild 
duóval a dokumentumfa egy részét tüntethetjük el, a Replace- 
Child-del pedig lecserélhetjük egy ágát. 

Az előbbi módosító műveletek elvégzéséhez oda kell navigál- 
nunk a megfelelő node-hoz. Rengeteg bejárási módszer létezik. 
Az egyszerűbbek a FirstChild, LastChild, ChildNodes és 
ParentNode jellemzőkön keresztül gyalogolnak a dokumentum- 
ban fel-le, de ezekkel elég kényelmetlen nagy mélységből vagy 
több helyről összeszedni a szükséges node-okat. A GetElements- 
ByTagName segítségével név alapján megkapjuk a névre illesz- 
kedő elemek listáját, tetszőleges szintről indulva és rekurzívan 
bejárva a dokumentumtöredéket. 

A legkényelmesebb és legrugalmasabb megoldás a SelectSingleNode 
és a SelectNodes metódusok használata, amelyek a paraméterként 
átadott XPath kifejezés alapján válogatnak le egy vagy több node-ot. 
A következő példában megtekinthetjük az előbbi metódusok egy 
részét az alábbi dokumentum feldolgozására (a.xml): 


£X?xml versions"1.0" encoding-"IS0-8859-2"?2 
cKNetAcademia?2 
€soci labmeret-"45"2Soczó Zsoltk/soci2 
€Kmarci labmeret-"49"2€C/marci2 
c/NetAcademia2 


Az üzleti probléma: Soczó Zsolt lába megdagadt a karácsonyi bejg- 
litől, így 46-osra változott. Fóti Marcell lába összement a síba- 
kancstól, így neki kettővel csökkent a lábmérete. Ráadásul a do- 
kumentumból hiányzik az útóbbi neve, c ly pótotjuk : azt. A kritikus 


let szemlélteti (a körítés ugyanaz, mint az előbbi példában): 
7/ XmiDocumenté2.cs 


XmiDocument d - new XmlDocument-( ); 
string docSource - "a.xml"; 

string docTarget - "b.xml"; 
d.Load(docSource) ; 


//soci elem labmeret attributumának 
7/kikeresése 

string xp - "/NetAcademia/soci/elabmeret" 
XmiNode n - d.SelectSingleNode(xp); 

//és módosítása 

n.Value — "Hb"; 


//marci elem labmeret attributumának 


//kikeresése property-kkel 
//SNetAcademia? 


Z2z0US. US: 


XmlElement gyoker - d.DocumentElement 
7/([(DO]:Ssoci2, [2]:Cmarci2 

XmlNode e - gyoker.ChildNodes[1]; 
//elabmeret 

XmlAttribute a - e.Attributes[0]; 


//XML dokumentumok kezelésekor nem string 
//típusú adatok konverziójára ne a szoká- 
//sos kasztolást ill. System.Convert osz- 
//tályt használjuk, hanem az XmlConvert- 
7/et. Ez az XSD spec-nek megfelelően 
//formáz illetve értelmez. 

int klab - XmlConvert.Tolnt32(a.Value) - 2; 
a.Value - XmlConvert.ToString(klab); 


77A marci elem tartalmának megkeresése 
XmlNode m - d.SelectSingleNode( "//marci"); 
XmlText t - d.CreateTextNode("Fóti Marcell"); 


//Az elem szöveges tartalama logikailag 
//az elem gyermek node-ja. 
m.AppendChild(t); 


d.Save(docTarget) ; 
A futtatás eredménye: 


€X?xml version-"1.0" encoding-"IS0-8859-2"?2 
GcKNetAcademia2 
£Xsoci labmeret-"4hb"2Soczó Zsoltk/soci2 
dKmarci labmeret-"47"2Fóti Marcellk/marci2 
c/NetAcademia2 


A kimenet nem egy nagy ömlesztett xml dokumentum, hanem 
egy szépen megformázott és tabulált doksi (nem én rendeztem 
be kézzel)! 

Ha sémával szemben ellenőrizve (validating) akarunk betölteni 
DOM-ba egy XML dokumentumot, akkor a Load() metódusnak 
nem egy fájlnevet, hanem egy inicializált XmlValidatingReader 
objektumot adunk át. Erről még fogunk értekezni egy későbbi 
számban, amiben az XML Sémával foglalkozunk. 


XPathNavigator 

A fenti DOM implementáció alternatívájaként a .NET biztosít egy má- 
sik megoldást is XML dokumentumok bejárására az XPathNavigator 
osztály formájában, ami a System.Xml.XPath névtérben található. 
Ez általában nem olvassa be az egész dokumentumot a memó- 
riába, csak azokat a részeket, amelyekre tényleg ránavigálunk. 
Persze ő is az XmIReader-re épít, csak nem olvassa be mohón az 
egész dokumentumot. Ezzel nyilvánvalóan jelentős időt és me- 
móriát spórol meg, ha csak a dokumentum egy részével foglal- 
kozunk. Az XSLT transzformációs osztály éppen ezért szívesen 
együttműködik vele, lehetővé téve nagyobb dokumentumok 
gazdaságos átalakítását. De erről kicsit később. 

Az XPathNavigator is egy absztrakt alaposztály. A használatához 
valahonnan szereznünk kell egy konkrét megvalósítást, ami mö- 
gött valamilyen valódi adatforrás áll. Három olyan osztály van, 
ami képes egy inicializált XPathNavigator készítésére, az XmIDo- 
cument (DOM, eddig erről volt szó), az XPathDocument és az 
XmiDataDocument. Az utolsóval a következő számban foglalko- 
zunk, most nézzük meg a másodikat, az XPathDocument-et. 

Az XPathDocument egy teljesítményoptimalizált, csak olvasható 
XML cache, amelyről lekérhetünk egy XPathNavigator példányt 
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az xml forrás gyors bejárására. Tehát ő a DOM-mal 
ellentétben nem tölti be a teljes xml doksit, csak a 
hivatkozott részeket olvassa fel, de azokat eltárolja 
(cache-eli), hátha később még el akarjuk érni. 

Könnyen el tudjuk képzelni, hogy például egy olyan XSLT 
transzformáció, ami csak a forrás egy kis részével foglalkozik, 
hatékonyan tud táplálkozni az XPathDocument-ből. 

Nézzünk egy egyszerű példát a használatára! 


XPathDocument doc - 

new XPathDocument( "a.xml"); 

XPathNavigator nav - 

( (IXPathNavigable) doc) . CreateNavigator ( ) ; 

XPathNodelterator iterator - 

nav.Select("/NetAcademia/t" ) ; 

while (iterator.MoveNext( )) 
Console.WriteLine(iterator.Current.Name) ; 


BAT ín E WU 


Létrehozunk egy XPathDocument objektumot, ami majd az 
a.xml-t fogja feldolgozni (2). Arról az IXPathNavigable interfé- 
szén keresztül tudunk lekérni egy XPathNavigator referenciát 
(4), ami az a.xml-t járja majd be. 

Az XPathNavigator Select() metódusában XPath kifejezés hasz- 
nálatával kijelöljük a feldolgozni kívánt xml részeket (6). A me- 
tódus kimenete XPathNodelterator típusú referencia, amelyen 
keresztül MoveNext()-tel végiglépkedhetünk a visszakapott xml 
elemeken (7). Ez tulajdonképpen egy node-halmaz. Az iterátor 
Current jellemzője újra csak egy XPathNavigator referenciát ad 
vissza, ami az aktuális node-on áll. A Name jellemző pedig en- 
nek a node-nak a nevét adja vissza, de természetesen további 
információk is lekérhetők az aktuális node-ról. 

Kimenet: 


soci 


marci 


Látszik, az hogy XPathNavigator egy kicsit olyan, mintha a DOM- 
beli XmlNode-ként viselkedne, vagy mintha mindig egy xml 
node képe látszana rajta keresztül. A (3) sorban ez az egész do- 
kumentumot reprezentáló node, az iteráció (8) során pedig az 
éppen aktuálisan elért node (soci, marci) . 

Úgy is elképzelhetjük a navigátort, mint egy kurzort a forrás xml-en. 
Lehet mozgatni, és mindig lekérdezhetjük éppen melyik node-on áll. 
A Select() mellett bejárhatjuk a navigátort egyéb mozgató me- 
tódusokon keresztül is. Ezek részben hasonlítanak a DOM-os be- 
járó metódusokra. Például a navigátorban egy xml elemen állva 
MoveToFirstChild() elmozgatja a kurzort a legelső gyermekelemé- 
re. Ehhez hasonló a DOM FirstChild jellemzője, ami visszaad egy 
referenciát az aktuális node legelső gyermekelem node-jára. A 
MoveToNext() továbblép az xml forrásban -— DOM nextSibling(). 
DOM kontra navigátor. Hogy melyiket használjuk rajtunk áll, ám 
dokumentumtöredékek feldolgozásánál mindenképpen érdemes 
fontolóra venni az XPathNavigator-t. Ez vonatkozik az előbbi 
nkézi" bejárásra és az XSLT transzformációkra is. 


XSL transzformációk 

Az egyik gyakran használt művelet xml források transzformáció- 
ja valami más xml vagy egyéb szöveges kimenetté. 

Ha adott a forrás xml fájl és az XSLT fájl, akkor transzformáció 
végrehajtása nagyon egyszerű: 


//XsilTransforml.cs részlet 
using System.Xml.Xsl; 
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XsliTransform s - new XslTransform-( ); 
xs.Load("traflh.xsl"); 
xs.Transform("atrafo.xml", "atrafoki.xml"); 


A példafájlokat illetve a teljes forrást a [2] címen lehet letölteni. 
Az XslTransform osztály azért ennél jóval okosabb. Gyakori fela- 
dat, hogy paramétereket kell átadni az XSL transzformációnak, 
így az a paraméterektől függő feldolgozást hajt végre a forrás- 


dokumentumon. 


7/ XsiTransforme.cs részlet 
7/XM1 forrás 

XPathDocument doc - 

new XPathDocument( 
GetXmlReaderCEU( "atrafo.xml")); 


XsiTransform xs - new XslTransform(); 


JAT ín E WU 


7/XSLT forrás 

20 xs.Load(GetXmlReaderCEU( "traf2.xsl")); 
11 

12 //Ebben lesznek a paraméterek 

13 XsltArgumentList xslArg - 

124 new XsltArgumentList(); 

15 //Két paramétert hozzáadunk 

lb xslArg.AddParam("kislab", "", 4b); 
17 xslArg.AddParam( "nagylab", "", 50); 
.18 

19 //Ebbe megy a trafo kimenete 

20 XmlTexturiter writer - 

2l new XmlTextWriter("atrafoki2.xml", 
22 Encoding.GetEncoding( "IS0-8859-e" ) ) ; 
23 

24 xs.Transform(doc, xslArg, writer) 


(3)-(5) sorokban a forrás transzformálandó dokumentumot ren- 
deljük hozzá egy XPathDocument példányhoz. Nem XmIDocument- 
hez, már tudjuk miért. A GetXmIReaderCEU() egy kis kényelmi me- 
tódus, ami XmlTextReader-t hoz létre a paraméterként megadott 
fájlra, IS50-8859-2, az Center European kódolást feltételezve. Ez 
szükséges, ha a forrás doksik vagy az XSLT-k ékezetes karaktereket 
tartalmaznak, és nem Unicode karakterenként vannak tárolva. 
Így néz ki: 


public static XmlTextReader 
GetXmlReaderCEU(string path) 
( 
StreamReader reader - 
new StreamReader (path, 
Encoding. GetEncoding( " IS0-8859-0" ) ) ; 
return new XmlTextReader(reader ) ; 


(7)-ben létrejön a transzformációs objektumunk, (10)-ben be- 
töltjük az XSLT-t. A transzformációban felhasznált paramétere- 


€Xxsl:stylesheet 
xmlns:xs1l-"http://www.w3.org/1999/XSL/Transform" 
version-"1.0"2 
£X1-- Ezeket a paramétereket töltjük 
ki híváskor. --2 
£xsl:param name-"kislab"/2 
£Xxsl:param name-"nagylab"/2 


Később a transzformációkban felhasználjuk a két paraméternek 
átadott értéket. A teljes XSLT letölthető a [2] címről. 


Ínyencek (perverzek) oldala 

Most pedig jöjjön egy kis ravaszság. Hogyan írjunk kiegészítő függ- 
vényt XSLT-ben, valamilyen menedzselt nyelven? Aki ismeri az 
MSXML script elemét, annak ez nem okoz nagy meglepetést, de aki 
még nem látott ilyet, az ámuljon. Már megint az XPathNodeltera- 
tor! A forrás node-set-jét így kapjuk meg paraméterül. Futtatás pél- 
dául az XslTaransform1.cs átírásával (trafo3.xsl). A kimenet: 49. 


£€xs1:stylesheet 
xmlns:xs1l-"http://www.w3.org/1999/XSL/Transform" 
xmlns:msxs1l-"urn:schemas-microsoft-com:xslt" 
xmlns:nacaz"http://www.netacademia.net" 
versionz"1.0"2 
£xsl:output method-"text" 
encoding-"IS0-8859-2"/2 


Xxmsxsl:script languagez"Ct" 
implements-prefix-"naca"2 
SIICDATA[ 
int LegnagyobbLab( 
XPathNodelterator iterator) 


int maxprice - 0; 
while (iterator.MoveNext()) 
( 
int price - System.Convert.Tolnt3e2e( 
iterator.Current.Value); 
if ( maxprice K price) 
maxprice - price; 
) 
return maxprice; 
) 
1 
£€/msxsl:script2 


£€xs1l:template match-"/"2 
£xs1l:value-of 
select-"naca:LegnagyobbLab ( / /elabmeret) "/2 
£€/xs1l:template2 
£€/xsl:stylesheet2 


Soczó Zsolt 
Zsolt.Soczo onetacademia.net 


ket egy XsltArgumentList objektumban rakjuk össze és adjuk át ES LLgTA SO ALATT 


transzformációnak (13-14). Az AddParam() hívás a paraméter 
nevét, névterét és értékét várja bementül (16-17). Az átalakítás 
eredménye egy XmlTextWriter-re megy (20-22), ahol a karakter- 
kódolásra ismét ügyelni kell. Végül a (24)-es sorban végrehajt- 
juk a mágiát, a forrás, a paraméterek és a cél felhasználásával. 
Az XSLT eleje így fest (traf2.xsl): 


[1]: .NET Reflector. 
http://www.aisto.com/roeder/dotnet 

[2]: Letölthető példák 
http://technet.netacademia.net/download/xml 
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SOL Server 


Join algoritmusok 


Az elmúlt alkalommal megvizsgáltuk a Ouery Optimizer működésének főbb alapelveit és 
kiveséztünk néhány egyszerű végrehajtási tervet (guery plan) . Most - ígéretemhez híven - 

a kapcsolási, avagy join stratégiák kerülnek sorra. Joggal kérdezhetik, hogy minek ez nekünk, 
hisz mindig minden automatikusan dől el az SOL Serverben. Ez igaz. De hogy milyen döntés 
születik automatikusan, azt súlyosan befolyásolhatják a mi korábbi tervezési döntéseink. 


S nem mellesleg: a Designing vizsgán a kérdések jó 159o-a a 
végrehajtási tervekkel foglalkozik! 

Egy-egy adatbázis még a legegyszerűbb esetben is több táblából 
áll, hiszen az adatbázistervezés egyik fő célja, a redundancia 
csökkentése a legkönnyebben úgy valósítható meg, hogy az is- 
métlődő adatokat a főtáblából kiemeljük, és külön táblába 
tesszük. Itt és most nem szeretnék elmerülni az adatbázistervezés 
rejtelmeiben (erre is sort kerítünk a későbbiekben), hanem kész, 
megtervezett és feltöltött táblák segítségével mutatom meg, mit 
tesz az SOL Server, amikor egy lekérdezés egynél több táblát 
érint. (Az egyszerűség kedvéért az , egynél több" ebben a cikkben 
mindig kettő. Nem fogunk hat-nyolc táblát összedzsoinolni, mert 
azzal feleslegesen bonyolítanánk a gondolatmenetet. Maga az SOL 
Server is így tesz: ha begépelünk neki egy nyolctáblás dzsoint, ak- 
kor a feladatot lebontja páronkénti összekapcsolásokra. ) 
Használjuk az egyszerűség kedvéért az SOL Serverben (is) meg- 
található Northwind adatbázist, s annak is két legnagyobb táb- 
láját, az [Orders] (rendelések, 830 sor) és az [Order Details] 
(rendelések tételei, 2155 sor) táblát. Éles adatbázisban a kétezer 
sor természetesen nem mennyiség, de kísérleteinkhez ez is ele- 
gendő lesz. Amint az az alábbi ábrán látható, az [Orders] táb- 
la elsődleges kulcsa az [OrderID] mező, melyen egy (clustered) 
index csücsül. Az [Order Details)] tábla elsődleges kulcsa össze- 
tett, két mezőt foglal magában: az [OrderID] és a [ProductID] 
mezőket. Az ehhez tartozó , gyári" index itt is clustered. 

(Az igazsághoz hozzátartozik, hogy az (Order Details] tábla ke- 
gyetlenül, feleslegesen és bután agyon van indexelve, mert az 
[OrderID] mezőn összesen három index van, s ezek közül kettő 
tökéletesen egyforma nonclustered index. Ez utóbbi kettő bátran 
törölhető lenne. Egyáltalán minek hozták létre?) 






CustomerID 
EmployeeID 
OrderDate 
ReguiredDate 
ShippedDate 
Shipvia 
Freight 
ShipWame 
Shipáddress 
Shipcity 
ShipRegion 









§ ProductID 
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0 A Northwind adatbázis két legnagyobb tábláját használ- 
juk joinkísérleteink végrehajtására 
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A két tábla úgy kapcsolódik egymáshoz, hogy az [Order 
Details] táblán van egy idegen kulcs, mely a két táblát az 
[OrderID] mentén köti össze. Ezt a relációt szokták one-to- 
many (egy a sokhoz) , vagy apa-fiú kapcsolatnak is hívni. 

De itt és most azonnal számoljunk le egy gyakori tévhittel: az áb- 
rán a táblák közötti referenciális integritási szabályt látjuk, mely 
csak azt határozza meg, hogy milyen rekordok születhetnek a két 
táblában, illetve milyen módosítás áldozatául eshetnek a meglé- 
vő adatok. Magyarán (és iszonyú röviden) : gyermekrekord nem szü- 
lethet apuci nélkül, és aput nem lehet legyilkolni mindaddig, amíg 
élnek a gyermekei. Azonban a referenciális integritási szabályok 
semmilyen korlátozást nem jelentenek a lekérdezésekre vonatko- 
zólag. A fennálló integritási szabály nem akadályozhat meg min- 
ket abban, hogy olyan lekérdezést írjunk, ami a két táblát például 
az [Orders].[ShipVia)] és az [Order Details].[Ouantity] mentén 
kapcsolja össze - legyen ez bármilyen értelmetlen feladat is (lásd 
később). Pusztán az értelmes felhasználás miatt szokás gyakorta 
ugyanúgy joinolni egy lekérdezésben, mint ahogy a referenciális 
integritási szabályok is állnak. 


Essünk neki 

Tákoljunk össze egy olyan lekérdezést, mely mindkét táblát 
megmozgatja, és vizsgáljuk meg ennek végrehajtási tervét. Kér- 
jük le az összes kapcsolódó rekordot! 


SELECT $ FROM 
[(Orders] INNER JOIN [Order Details] ON 
[(Orders].[OrderID] - [Order Details].[OrderID] 


Gondolkodjunk az SOL Server fejével! Hogyan lehetne előállíta- 
ni a fenti lekérdezés eredményét, mely minden egyes [Order 
Detail] sorhoz keresi annak ,apukáját" az [Orders] táblában? 
Két stratégia is kínálkozik. Az egyik, hogy végigszaladunk az 
[Order Details] táblán, és soronként kikeressük hozzá a megfe- 
lelő aparekordot. A másik módszer szerint az aparekordokon 
gyalogolunk végig egyesével, és megkeressük minden sorhoz az 
összes gyermeket. Programózói szakzsargonnal: két egymásba 
ágyazott ciklust használunk; az egyik táblán végigszaladunk egy 
ciklussal (ez a külső, outer ciklus) , s ennek minden állomásán le- 
futtatunk egy másik ciklust (belső, inner) a másik táblán. Ezt a 
stratégiát Nested Loopnak hívják, és a Ouery Planen így fest: 


NEG. BZ: 
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te) Nested Loop 


Az SOL Server úgy állapítja meg, hogy melyik ciklus 
melyik táblán fusson, hogy rá se pillant a referenciális 
integritásra. Az esetek elsöprő többségében a kisebb (ke- 
vesebb rekordszámú) táblán fut a külső ciklus - így ,olcsóbb". 
Tehát a mi esetünkben az [Orders)] lesz a külső, és az [Order 
Details] - mely vagy háromszor annyi sort tartalmaz - lesz a 
belső. Lássuk.a tervet! 


EL. S sáp 
98 Ti S-I 





SELECT Merge Join/ Inne.. Orders.PK Order... 
Cost: Os Cost: 115 Cost: 47$ 
dösszzzzzzzti 





Order Details.P... 
Cost: 415 


a A fenti joinos SELECT futtatási terve. Nested Loopra szá- 
míitottunk, ehelyett Merge Joint kaptunk 


Hümm. Ez bizony nem Nested Loop! Ez egy teljesen másik join 
stratégia, az úgynevezett Merge Join. Az igazat megvallva én 
ezt előre tudtam. Az egymásba ágyazott ciklusokat használó 
Nested Loop ugyanis a legalapvetőbb, és legegyszerűbb straté- 
gia. Emlékeim szerint SOL Server 6.5-ig bezárólag csak ez a stra- 
tégia létezett. A következő verzió, a 7.0 - mely kenterbe verte 
elődjét az összes teljesítményteszten - többek között azért tu- 
dott sokszorosan nagyobb teljesítmény nyújtani óriási adatbá- 
zisok esetén, mert két újabb join stratégiát okoskodtak ki a red- 
mondi fejlesztők: a Merge és a Hash joint. Ezek megértéséhez a 
megfelelő alapok már rendelkezésre állnak, hisz tavaly október- 
ben kimerítő cikket írtam a hash algoritmusokról (a húsdarálós) . 


Mi a baj a Nested Looppal? 

Két nagy baj van vele: az, hogy Nested és az, hogy Loop. Az 
egymásba ágyazott ciklusok miatt ugyanis a belső ciklus annyi- 
szor fut le, ahány lépése van a külsőnek. Azaz, ha a külső cik- 
lus 830 sort talál, akkor a belső táblát bizony 830-szor , vesszük 
kézbe". Ha a táblák még nagyobbak, a helyzet egyre csak rom- 
lik. Tegyünk egy kísérletet, mérjük össze a Nested Loop és a 
Merge Join sebességét és viselkedését ezen a két táblán. Ehhez 
elsőként állítsuk be a Ouery Analyzert úgy, hogy mérje a futta- 
tási időket, valamint hogy hányszor kell a táblákhoz nyúlni 
(Tools-2Options-2Connection Properties fül): pipáljuk be a Set 
statistics time és a Set statistics IO opciókat! 


Vizsgára készülők figyelmébe! 

Minden, ami egérrel bekattintható, az Transact SOL paran- 
csok segítségével is beállítható. Ezeket érdemes vizsgára 
menetel előtt áttekinteni, bemagolni, majd a vizsga után 
lazán elfelejteni. Jelen esetben a 


SET STATISTICS TIME ON 
SET STATISTICS IO ON 


Parancsokkal érhető el ugyanaz a hatás. 
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£ 21 
Connection Properties ] Fonts  ] Script ) 


General] Edítor ] Results] Connections 





IT Setnocount 

TT Setnoexec 

I Set parseonly 

FF Set concat null vields. null 


Set rowcount 0 


[7 Set ansi defaults 
[7 Setansi nulis 
[7 Set ansi null dít on 
F Set ansi padding 
F7 Set ansi wamings 


[7 Set arithabort 








IT Set cursor close. on. commit 
T Set implicit transactions 
I Set guoted identilier 


Reset All 
Pos 1 eme] ven] Hop] 


5 Felkészítjük a Ouery Analyzert kétféle teljesítménystatisz- 
tika gyűjtésére. Az IO mérés alapvetően a 8k-s lapok felhasz- 
nálásának számlálására való 











Ha ezekkel a beállításokkal lefuttatjuk a cikk eddigi egyetlen, 
fentebb olvasható joinos SELECT lekérdezését, a következő ered- 
ményeket kapjuk: 






(2155 row(s) affected) 


Table "Order Details". Scan count 1, logical reads 10, physica. 
Table "Orders". Scan count 1, logical reads 21, physical reads 


OL Server Execution Times: 

CPU tíme - 90 ms, elapsed time - 443 ms. 
SOL Server parse and compile time: 
CPU time - 0 ms, elapsed time 5 0 ms. 


C Giids (ÍJ Messages 


5 Táblázatos kimenet esetén a teljesítménymérés eredménye 
a Messages fülön jelenik meg. Ez itt a Merge join eredménye 


Feljebb olvasható az IO statisztika, alant a futási idők. 

-8 Scan count: ennyiszer kellett hozzányúlni az adott táblához. 
Könnyedén leolvasható, hogy mindkét táblát egyszer , fog- 
tuk meg" 

B Logical reads: az olvasás során feldolgozott 8k-s lapok száma. 
10 és 21. Nem rossz! 

"8 Physical reads: hány olyan 8k-s lap volt, amit a lemezről kel- 
lett felemelni - merthogy nem volt a kessben. Miután én már 
ikszedik alkalommal futtattam ezt a lekérdezést, mindkét tábla 
bekúszott a kessbe, így ez a mutató mindkét táblánál nulla.( Az 
ábrán nem látszik kilóg). 

A végrehajtási idők közül a CPU time számít: ez 90 ms. Ezekkel az 
eredményekkel kellene összevetni a Nested Loop stratégia eredmé- 
nyeit, de ehhez rá kellene venni az SOL Servert, hogy hagyja a Merge 
joint a csudába. Ezt úgynevezett optimizer hintekkel (súgásokkal) 
tehetjük meg. De vigyázat! Optimizer hintet csak és kizárólag tesz- 
telési célból használjunk, mert ha belevarrjuk az alkalmazásba, óriá- 
si hibát követünk el! Lásd az előző cikkem elrettentő példáit! 


Erőszakoskodás Optimizer hintekkel 

A Books Online részletesen taglalja az optimizer hinteket, me- 
lyik mire jó, hogyan lehet segítségükkel zárolást, indexhaszná- 
latot, dzsoinstratégiát rálőcsölni szegény SOL Serverre. Ha a 
fenti egyetlen SELECT végére odabiggyesztjük, hogy 


eú0R:. BZ: 


SELECT 4 FROM 
[fOrders] INNER JOIN [Order Details] ON 
[Orders].[OrderID] - [Order Details].[OrderID] 


dus JI 1 


akkor ugyanez a lekérdezés Nested Loop stratégiával fog lefut- 
ni. Az alábbi táblázat segítségével könnyedén összehasonlítha- 
tó a két joinstratégia teljesítménykülönbsége. A könnyebb 
összehasonlítás kedvéért csak az egyik tábla, az (Order Details] 
adatait foglaltam össze: 


eler 8 (dl Mer Hej uj 


Scan count 1 830 
Logical reads 10 1672 
CPU time 90 130 


Világosan látszik a Nested Loop katasztrofális teljesítménye, 
melynek oka: egymásba ágyazott ciklusok nagy táblákon. A fu- 
tásidő csak azért nem változott még ennél is drámaibban, mert 
a két tábla viszonylag pici, és ráadásul kessben van. De nem 
ereszteném rá a Nested Loopot több millió soros táblákra! 
Félreértés ne essék: ez nem azt jelenti, hogy a Nested Loopot 
tűzzel-vassal irtani kell, mert megvan a maga szerepe. Ha a két 
tábla közül akár az egyik icipici, máris sokkal gyorsabb, mint 
akár a Merge, akár a Hash! 

Ha a fenti WHERE feltétel nélküli SELECT-et ellátjuk szűrőfeltétellel: 


SELECT § FROM 
[Orders] INNER JOIN [Order Details] ON 
[Orders].ÖrderID - [Order Details)].OrderID 
[dalai zi 
[(Orders] . rderID-10248 


akkor az [Orders] tábla máris pici lesz (3 sort talál a lekérde- 
Zés), és az SOL Ouery Optimizer már hajítja is el a Merge joint, 
és automatice visszavált Nested Loopra. 

Ha most ezt a WHERE feltételes lekérdezést erőszakoljuk meg, 
és szándékosan Merge joinba kényszerítjük, szintén katasztrófa 
lesz a vége. Nem is akármilyen katasztrófa! Kapunk egy 8622-es 
hibaüzenetet, mely szerint: 


,Ouery processor could not produce a guery plan because of 
the hints defined in this guery. Resubmit the guery without 
specifying any hints and without using SET FORCEPLAN." 


Ajjaj! 


Vigyázz! Warning! Pozor! 
Soha ne varrj be Optimizer hinteket a kódodba! Isten tud- 
ja, mi lesz belőle később! 


Mire nem jó a Nested Loop? 
a Nested Loop stratégia használhatatlan many-to-many lekérde- 
zéseknél (cross joinnál, vagy másnéven cartesian productnál) 


IEz:! Merge join 


Ha már annyi szó esett a Merge Join fantasztikus teljesítményéről, 
itt az ideje, hogy megtudjuk, mit csinál másképpen, mint a Nested 
Loop. Azt már a fenti táblázatokból is láthattuk, hogy mindkét táb- 
lán csak egyetlenegyszer megy végig. Vajon hogy csinálja, hogy 
nem kell visszafordulnia? Ez csak egy módon képzelhető el: ha a re- 
kordok mindkét táblában rendezetten érhetők el, vagyis vagy 
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8 van jó index, mely segít a joinmezőkön végig- 

futni, vagy 
-8 a Merge előtt lefut egy logikai sorbarendezési 

művelet (Sort) 
A Merge joinnak két lába van. Az egyikkel az egyik tábla re- 
kordjain csoszog előre, a másikkal a másik táblán. Előrelép az 
egyikkel, talpa alatt egy kulcsmező, melynek értéke mondjuk 
10248. Ezután a másik lábát addig csúsztatja előre a másik táblán, 
amíg ott is 10248 van a talpa alatt. Ha túlfut, megáll, és megint 
az első lábát kezdi húzni mindaddig, amíg az első táblában olyan 
rekordokat talál, mint amelyiken a másikon áll. Mint ahogyan az 
ember a jégen megy. Egyik lábát addig tolja előre, ameddig csak 
bírja (vagy be nem szakad), s utánahúzza a másikat. 
Mivel jó index mentén csoszogó Merge joint már láttunk az elő- 
ző oldalon, most nézzük meg, hogyan fest egy indexmentes, 
vagy használhatatlan indexekkel , segített" lekérdezés futtatása. 
Egy extrém példával együtt említettem, hogy a referenciális in- 
tegritásnak vajmi kevés köze van a join stratégiákhoz, azt join- 
ulunk össze és azzal, amit csak akarunk. Akár teljesen értelmet- 
len dolgokat is összekapcsolhatunk: 


SELECT : FROM [Orders] 
INNER JOIN [Order Details)] ON 
[Orders].[ShipVia)] - [Order Details)].[duantity] 


Ez a lekérdezés kilistázza azokat a rekordokat, ahol a rendelések 
szállítási módja egyenlő a szállítási mennyiséggel :-) 
A végrehajtási tev elgondolkodtató: 


SELECT Herge Join/Inne. .. Sort Orders.PK Order. . 





ha — Má — 


Cosc: 184 Cost: 04 Cost: 174 


a Ha nincs (jó) index, a Merge Join csinál magának. Ez a 
Sort műveletből látható. Tekinthetjük dinamikus indexnek, 
melyet a lekérdezés végén elhajítunk. 


Mintha indexet használna a sorbarendezés (Sort) művelet előtt! Ez 
azonban optikai csalódás. Az ábra jobb szélén ugyanis Clustered 
Index Seeket látunk, ami a közönséges táblavégignyálazás (Table 
Scan) helyett jelenik meg a táblán, melynek fizikai sorrendjét a 
clustered index határozza meg. 


Mire nem jó a Merge join? 
A Merge Join használhatatlan, ha a join operátor nem egyenlő- 
ségjel (hanem c, sz stb.) 


e Hash join 


És végül, de nem utolsósorban, itt a hash join. Amilyen nehéz 
volt elképzelni, hogy mi kellhet a Nested Loopon kívül, épp 
olyan nehéz felfogni, hogy mi maradt, amit a Merge joinnal sem 
lehet megoldani. Pedig van ilyen join probléma: hatalmas táb- 
lák index nélkül! Ilyen nincs ugye? De bizony van. Még véletle- 
nül, hanyagságból is előfordulhat. Vagy egy olyan ad-hoc lekér- 
dezést kér a marketingfőnök, ami a vevők lábméretét összedzs- 
oinolja a raktárkészlet újrarendelési küszöbével :-) Egyszóval 
olyan lekérdezés, amire nincs index, és nem is érdemes csinál- 
ni, mert több órán keresztül tart, és utána nem kell semmire. 
Mi a hash? Egy húsdaráló. Mit darál? Bármit. Mi lesz belőle? Fa- 
sírt. Digest. Egy olyan érték, mely jellemző arra a bemenő adat- 
ra, amit bedobtak a darálóba. 
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Mi lehet a célunk két irdatlan nagy, indexmentes 
tábla összejoinolásakor? Hogy ne kelljen unos-unta- 
lan végigtekerni az egyik táblán, hogy párt találjunk 
hozzá a másikban. Erre találták ki az indexeket, dehát 
nincs nekünk olyan. 

Elő kellene venni a tech.net tavaly októberi számát, ugyanis 
ott, a Hash! című cikkben részletesen elmeséltem a nagy halma- 
zokban történő keresés gyorsítását Pistikével, és a tanító néni- 
vel, akinek Pistike rágógumit rakott a székére. Ha az osztályba 
tízmillióan járnak, sokkal gazdaságosabb keresést biztosít, ha 
Pistike önként jelentkezik, mint ha mind a tízmillió kis csibészt 
végigkérdezem. Mivel Pistikének esze ágában sincs jelentkezni, 
a tízmillió csirkefogó gyereket bizonyos jellemzőjük alapján cso- 
portokba (hash buckets) rendezzük, és csak a ,gyanús" csopor- 

tokat vizsgáljuk át. A többiek hazamehetnek. 


Ez történik a hash joinnál 

Van két táblánk, külön-külön foglalkozunk velük. Először a ki- 
sebbiken megyünk végig, s a joinban használt (kulcs?)mezőre 
ráeresztünk egy hash algoritmust (hogy melyiket, azt sajnos nem 
találtam meg az általam átböngészett szakirodalomban) , majd az 
így előállt kulcs-hasheket vödrökbe (bucket) szortírozzuk. 


5345243 


Hash! 


a TB a 


5 Hash buckets, melyekbe az egyedi hash értékek szétválo- 
gatódnak. Így egy rekord keresése csak egy vödör átbogará- 
szását igényli, nincs szükség a teljes tartomány átfésülésére 


Amikor ez megvolt, jöhet a második tábla feldolgozása. Szépen, 
egyesével kiszámítjuk minden rekord kapcsolómezőjéhez a hash 
értéket, s megnézzük, vajon melyik vödörben lehet a párja. Az 
adott vödör tartalmát azután egyesével átfésüljük, míg meg 
nem találjuk a kívánatos érték(ek)et. Ilyen egyszerű! 
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Mit is nyertünk ezzel? Azt, hogy bár két hatalmas, indexmentes 
táblánk volt, mégis elegendő volt egyetlenegyszer végigmenni 
mindegyiken, hogy megtaláljuk a joinnak megfelelő sorpárokat. 
Íme itt egy hash végrehajtási terv, melyet a megfelelő optimizer 
hint segítségével kényszerítettem ki: 








ag 
Ves d SI 

SELECT Hash Hatch/Inne. . Orders.PK Order... 
Cost: 15 Cost: 674 Cost: 175 


— Ha — s 
Compute Scalar Order Details.P... 
Cost: Oz Cost: 157 


5 Hash join a két táblán. Csalással (hint) készült, mert a táb- 
lák nem elég nagyok ahhoz, hogy ezt válassza az SOL Server 


Mire nem jó a Hash join? 

Tavaly októberben még nem tudtam, hogy az SOL Serverben fel- 
használt hash algoritmus egyedi értékeket ad-e. Most már tu- 
dom. Egyedi értékeket ad. Emiatt sajnos a hash joinra ugyana- 
zok a korlátozások érvényesek, mint a merge joinra: a join- 
feltételnek egyenlőségnek kell lennie. Ha nem az, akkor gigan- 
tikus táblák esetén is marad a jó öreg Nested Loop, bár annak 
egy érdekes változata, amikor a ciklusok csak a kulcsokat pároz- 
tatják össze, mert az összes rekord nem fér be a memóriába. Ha 
kész a kulcsokra a ciklus, utólag, külön lépésben halássza-va- 
dássza össze a teljes rekordokat. Álljon itt mementóul egy 
Bookmark Lookupos, Nested Loop, hogy érzékeljük a Ouery 
Optimizer határtalan bölcsességét: 





a — s — fi -— 8 
SELECT Bookmark Lookup Nested Loops/In, . Order Details.P... 
Cost: 15 Cost: 18r Cost: 235 Cost: 11£ 


Orders.Shippers... 
Cost: 485 


5 Nested Loop, de a teljes eredményhalmaz nem fért be a 
memóriába. Ilyenkor először csak a kulcsokat loopolja össze, 
majd Bookmark Lookuppal szedegeti fel a rekordokat 


Mostanra elég sokmindent végigvettünk a Ouery Optimizer lehe- 
tőségei közül. Nem célom az összes kis ikon végigmagyarázása, 
de ha találok még érdekességet a témában, ígérem, megírom. 
Legközelebb azonban a zárolások következnek. Mi az a Deadlock? 


Fóti Marcell 


MCDBA 
marcellf-onetacademia.net 
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2001 október közepétől a Netacademia Kft üzemelteti Magyarország egyik 

legnagyobb letöltőközpontját. A Microsoft Magyarország megbízásából elkészült oldalak az 
eddig megszokott tartalommal, de eltérő formában jelentkeznek. Az új megjelenés könnyű 
kereshetőséget, világos, áttekinthető formát biztosít a látogatók számára. Az innen 
letölthető programok közül csemegézünk ebben az új rovatban. 


A Microsoft hivatalos letöltőközpontjában [1] időről-időre meg- 
jelennek olyan anyagok, amelyek valamilyen módon kiemelked- 
nek a szokásos ingyenanyagok közül. Ezekre szeretnénk felhívni 
a figyelmet ebben a rovatban. 


Halmozott javítás Internet Explorerhez (MS01-55) 

2001. november 8-án a Microsoft egy olyan javítást adott ki, amely 
nem javított ki minden biztonsági rést az IE 5.5 és IE 6.0 böngé- 
szőprogramokban. Rövid időn belül be is vonták az így kiadott biz- 
tonsági javítást, majd november 13-án már egy újabb verzióval ta- 
lálkozhattunk, mely már valóban orvosolja az alábbi hibákat. 

Ezek a rések egyrészt abból adódnak, ahogy az Explorer a cookie- 
kat kezeli. A ,sütiken" keresztül felépíthető volt egy olyan el- 
lenőrizhetetlen kapcsolat, amellyel mélyebben fekvő információk- 
hoz hozzá lehetett férni, sőt azokat bizonyos esetben módosíta- 
ni is lehetett. Másrészt néhány weboldal érzékeny információkat 
tárol egy-egy cookie-ban (például felhasználónév-jelszó páros) , le- 
hetővé téve ezen személyes információkkal való visszaélést. 

A fejlesztők ebben a hotfixben kijavítanak egy másik hibát is, 
amely az MS01-51 számú biztonsági javításban orvosoltak egy 
újabb fajtája, nevezetesen a , fertőzések pontnélküli URL-eken 
keresztül" fedőnevű. 

Ha egy weboldalt a pontnélküli IP címével hívunk meg (például 
http://031713501415 a http://207.46.131.13 helyett), és a 
megadott cím létezik, akkor az Internet Explorer nem ismeri fel, hogy 
a megadott cím egy Internetes oldalt takar. Ehelyett úgy kezeli, 
mintha intranetes lenne és ezért helytelenül az intranet zónában 
nyitja meg. Így pedig az adott oldalnak kevesebb védelmi előírásnak 
kell megfelelnie. Ez a hiba az Explorer 6.0-át már nem érinti. 


Azok, akik a november 8-án kiadottaknak megfelelően jártak 
el, és Explorer-ükben letiltották az Active Scripting funkciót, 
újra engedélyezhetik azt ezen javítás telepítése után. 


Újabb rések betömése az Internet Explorerben (MS01-58) 

Újabb biztonsági réseket javíthatunk ki Explorerünkön, ha a Micro- 
soft által 2001. december 13-án kiadott hotfixet telepítjük. Ez tar- 
talmazza az eddig ismert minden hiba javítását, amit az Internet 
Explorer 5.5 SP2-ben és az Internet Explorer 6.0-ban felfedeztek. 
Ezentúl három új támadási felületet tudunk vele megszüntetni. 

1. Az egyik illetéktelen behatolásra éppen a HTML fájlok felépí- 
tése adja meg a lehetőséget. A HTML fájlok fejrészében több 
olyan adatot is elhelyezhetünk, ami az adott oldalról közöl kü- 
lönböző információkat. Ezek közül kettő, a Content-Disposition 
és a Content-Type mezők azt a környezetet hivatottak leírni, 
hogy az oldal letöltése után az böngésző hogyan kezelje az át- 
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küldött információt. Ez azért veszélyes, mert így egy futatható 
állományról az Explorer elhiszi, hogy ártalmatlan HTML fájllal áll 
szemben, és bármilyen figyelmeztetés vagy felhasználói jóváha- 
gyás nélkül megnyitja azt. Így egy rosszindulatú HTML levél 
vagy weboldal megnyitásakor egy exe állomány kezd futni gé- 
pünkön, kisebb vagy nagyobb bosszúságot okozva. Ez a bizton- 
sági hiányosság csak az IE 6.0-t használókat érinti, aki IE 5.5 
SP2-vel rendelkezik, védve van az efféle támadásoktól. 
Mivel a legtöbb ilyen behatolási próbálkozás az Internet vagy 
intranet zónából érkezik, ezért ebben a két zónában az 
alapértelmezett File Download (fájl letöltés) engedélyezést til- 
tásra kell átállítani. Így kivédhetünk minden hasonló esetet. 
2. A másik biztonsági rés a már kiadott MS01-15-ös számú bizton- 
sági javításban közöltek egy újabb verziója. Ez egy rosszindulatú 
webszerkesztőnek megengedi, hogy két böngészőablakot nyisson. 
Az egyiket a weboldal domain-jében, a másikat pedig a felhaszná- 
ló rendszerében. Így minden olyan fájlhoz hozzáfér, amit egy bön- 
gészőben meg lehet nyitni. Ha gépünket egy ilyen hívatlan látó- 
gató eléri, akkor bármilyen képet, szöveges állományt, vagy HTML 
fájlt képes megnyitni és elolvasni, amit eltároltunk. A többi fájltí- 
pushoz, mint például a bináris, futtatható állományok vagy Word 
dokumentumok, nem fér hozzá. Azon túl, hogy bizonyos fájlok tel- 
jes tartalmához hozzáfér, a fájlok pontos nevét és helyét is meg 
tudja állapítani. , Csak" olvasási joggal rendelkezik, tehát se töröl- 
ni, se állományt létrehozni, módosítani vagy futtani nem tud. Ez 
a rés viszont már mind az IE 5.5-öt, mind az IE 6.0-t érinti. 
3. A harmadik biztonsági hiányosságot a File Download (Fájl le- 
töltése) ablakban fedezték fel. Amikor egy fájlt szeretnénk letöl- 
teni, akkor egy dialógusablak jelenik meg, ahol a fájl nevét a 
rendszer automatikusan kitölti. Bizonyos esetekben előfordul- 
hat, hogy rendszerünket úgy próbálják megtámadni - legyen az 
weboldal vagy HTML formátumú levél -, hogy a fájlnév kicsit el- 
ferdítve kerüljön ebbe a mezőbe. Például megváltozik a kiter- 
jeszés vagy akár csak egy betűnyi különbséget találunk. Ám ez 
elég, hogy egy korántsem biztonságos fájlt letöltsünk. 
Az, hogy egy fájl letöltését engedélyezzük, soha nem azon alap- 
szik, hogy milyen kiterjesztéssel rendelkezik az adott állomány, 
hanem azon, hogy a forrásban mennyire bízunk meg. Ezért meg- 
bízhatatlan forrásból ne töltsünk le fájlokat, még akkor sem ha 
a típusa egyébként megbízhatónak tűnik. 
. Borsi Katalin 
bobo onetacademia.net 


A cikkben szereplő URL-ek: 


[1] http://msdownload.netacademia.net 
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Rendszerváltás 


IPvó 


" Csak semmi aggodalom! Most nem hullanak fejek, nem cserélik le az utcatáblákat, és 
azt sem írják elő, hogy hány ágú, milyen színű csillagokkal díszíthetjük a karácsonyfát. 
Szerencsére másról, sokkal érdekesebbről és hasznosabbról lesz szó: az Internetről. 
Helyesebben annak, gyakorlatilag egyeduralkodó protokolljáról, az Internet 
Protokollról (IP), amelynek jelenleg a 4-es számú verzióját használjuk. 


A 4 bájtos címmezővel ábrázolható, mintegy 4 milliárd IP cím 20 
évvel ezelőtt olyan nagynak tűnt a protokoll kidolgozói számára, 
hogy végül mégiscsak kevés lett. A bőség zavarának köszönhetően 
fordulhat elő ma olyan eset, hogy egyetlen egyetem nagyobb cím- 
tartománnyal rendelkezik, mint egy egész ország. Az osztályos IP 
világban nem lehetett szűkmarkúnak lenni: a C osztály sok szerve- 
zet számára kevésnek bizonyult, és már a B-vel is egyszerre 65536 
cím veszett el - akkor is, ha csak 300 kellett volna. Az Internet 
robbanásszerű növekedése hamar jelezte, hogy nem lesz ez így jó, 
így vérmentes forradalom keretében felszámolták az osztályokat, 
az így létrejött, ma is működő világot pedig CIDR-nek (Classless 
InterDomain Routing) nevezték el. Ezenkívül a NAT (Network 
Address Translation) is segédkezet nyújtott, hiszen ekkor egyetlen 
cím mögé egy újabb Internet bújhat. 

Az Internet rengeteg alkalmazást rejt magában. Hűtőgép, amely 
kaját rendel az áruházból; autó, amely kinyitja a garázsajtót, 
csomagkapcsolt" TV; kommunikátor stb. Némelyiket már ma 
használjuk, és feltehetően a többi megszokása is csak idő kérdé- 
se. Bármennyire is úgy tűnik ma, hogy sosem lesz rájuk szükség, 
a következő generáció tisztelettel adózik majd előttünk, hogy 
ezek nélkül is képesek voltunk a túlélésre. Igény tehát van. 
Amilyen gyakori ma a cég-, termék- és technológianevekben az e és 
az x betű, olyan gyakori lesz néhány éven belül a 6-os szám: ftp6, 
ping6, tracertő stb. Ezek mind az IP új, 6-os számmal jelölt verziójá- 
ra épülnek. Az IPv6 egyik legfontosabb tulajdonsága, hogy a címe- 
ket 16 bájtosra növelték, így Tannenbaum érzékletes példája szerint 
a Föld minden négyzetméterére 1000-nél is több cím jut. Ha az Egye- 
sült Nemzetek előrejelzése szerint 20 év múlva 10 milliárd ember ta- 
possa ezt a bolygót, az akkor is fejenként több mint 1 millió cím. 
Nyilvánvaló - hiszen nem lenne most miről írnom, ha nem így 
lenne, - hogy a Microsoft sem figyelte tétlenül az IPv6 fejlődé- 
sét. A kutatási részleg, Draves és Zill személyében már 1996-ban 
bekapcsolódott az IETF szabványosítási munkájába. Először az NT 
4.0 TCP/IP forráskódját írták át, de mivel ez nem minden terüle- 
ten adott kielégítő eredményt, egy módosított változattal álltak 
elő. Az MSRIPv6 1.0 1998-ban jelent meg. Draves és Zill kérésére 
a Microsoft Windows részlege nemcsak a kód megváltoztatását 
engedélyezte, hanem merőben szokatlan módon a forráskód nyil- 
vánosságra hozását is. Elkezdődött egy új közösség kialakulása, 
szoftverrel, levelezőlistával, eszmecserével. 2000 elején letölthe- 
tő volt a Windows 2000-hez a technology preview, vagyis amo- 
lyan bemutató jellegű termék. Ehhez már API is tartozott, tehát 
a vállalkozó kedvűek alkalmazásokat készíthettek hozzá. Végül, 
2001-ben az XP bétában ott díszeleg a fejlesztői változat. Terveik 
között ott szerepel a .NET Server-hez kapcsolt IPv6 protokollve- 
rem kereskedelmi változata, amelyhez már a támogatás is dukál. 
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Ez a bámulatos lendületesség nem véletlen. Nagyon nagy a tét. A ko- 
rábban felsorolt alkalmazási lehetőségek közül a mobil világ és az 
Intemet konvergenciájából (3G: 3. generáció) születő kommunikátor- 
szerű kütyük közeljövőbeli áradata a legvalószínűbb. Ebben a felvo- 
násban még nem tisztázódtak teljesen a szerepkiosztások, de a jelek 
szerint teljesen világos, hogy a Microsoft nem statiszta akar lenni. 
Némi általános vita jellemzi azt a kérdést, hogy az átállást a 
hardverrel vagy a szoftverrel kell-e kezdeni? A Microsoft mint 
szoftvercég, eléggé el nem ítélhető módon reagált a kihívásra. 
Huitema kidolgozta a 6to4 módszert, amivel minden egyes IPv4 
címhez egyértelműen rendelhető IPv6-os prefix (a hálózati maszk 
jogutódja). Eszerint minden IPv6-os implementációnak ismernie 
kell majd a 6to4 módszert: amikor ilyen célcímmel találkoznak, 
akkor az IPv6-os címből IPv4-est kell előállítani, és az eredeti 
IPv6-os csomagot az előállított IPv4-es célcímmel IPv4-es mó- 
don kell becsomagolni (tunnelling) . 
Térjünk vissza egy kicsit a 36-hez. A mobil világ alapvetően ide- 
gen az Internettől. Mert milyen dolog az, hogy valaki fogja ma- 
gát, aztán egyetlen lépéssel egy másik országban lévő útvonal- 
választó mögé kerül? Pedig ilyen bizony gyakran előfordul majd, 
hiszen nemhogy tiltani nem akarják a szolgáltatók az efféle skan- 
dallumot, hanem egyenesen bátorítják. Végülis ezért hívják mo- 
bilnak. De mit csinál ilyenkor az IP? Az eredeti címmel már nem 
tud mit kezdeni a kedves felhasználó, mert az útvonalválasztók 
csakazértis az eredeti helyére küldik a csomagokat. Az útvon- 
alválasztási táblázatok átírása kissé körülményesnek, és legfő- 
képpen lassúnak tűnik, arról nem is beszélve, hogy mennyi sáv- 
szélességet kötne le teljesen feleslegesen. A megoldás az 
(legalábbis egyelőre), hogy a vendéglátó ad új címet, mi meg ha- 
zaszólunk, hogy most éppen hol vagyunk elérhetők. Ezt a mód- 
szert mobil IP-nek hívják, és távolról sem ilyen egyszerű. 
Olyannyira nem, hogy erről még RFC sem született, és egyetértés 
hiányában egyik draft követi a másikat. A Microsoft természete- 
sen ebben a küzdelemben is részt vesz, kicsit elmaradva ugyan a 
legfrissebb draftoktól, de a protokoll körüli zűrzavar fényében ezt 
igazán nem róhatjuk fel nekik. Aktualitása miatt legközelebb a 
mobil IPv6 protokollt és annak microsoftos vonatkozásait fogom 
bemutatni. Az érdeklődőknek addig is azt javaslom, hogy látogas- 
sák meg az [1] weboldalt, töltsék le, és próbálják ki a legújabb 
MSRIPv6-ot! Kellemes élményben lesz részük. 
Zacco 
zacco ofw.hu 
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[11 http://research.microsoft.com/msripv6/msripv6.htm 
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Windows 2000 

A meghatalmazotti kapcsolat (trust) leleplezése. 

Oknyomozó riportunkban annak járunk utána, hogy vajon a Windows 2000 Professional és Windows XP eltér- 
e a kiszolgálóváltozatoktól (Server és Advanced Server), és ha igen, miért nem. Bebizonyítjuk, hogy a munkaál- 
lomásváltozatok is képesek trust kapcsolat létrehozására - még ha a szakma nem is annak hívja e lépést. 


XMLgessünk 

XML.NET III. 

Hogyan lehet egy relációs adatbázis adatai XML-ként látni és kezelni, transzformálni? Nem SOL Serveren. 
Hogyan lehet XML adatokat relációs adatként láttatni? Hogyan lehet ez minimális programozással megten- 
ni? Ezekről beszélünk a következő részben, természetesen .NET alapon. 


:NETAcademia 

, NET alaptípusok II. 

Folytatjuk a Common Type System feltérképezését az interfészek fogalmával, a közös ős, a System.Object 
szolgáltatásaival, valamint az érték- és referenciatípusok használatával. 


ASP Suli: 

Még mindig WAP 

Miután nagyjából megismertük a WML nyelv felépítését és működését, nekikezdhetünk az első wapos 
weboldalunk létrehozásának. A következő számban bemutatjuk, hogyan kell ehhez az Internet Information 
Services beállításait módosítani, illetve áttekintjük a fejlesztéshez használható eszközöket, és azok használatát. 


RIS: 

Telepítőkészletek 

CDROM alapú vagy RIPREP telepítőkészletet válasszunk? Előnyök, hátrányok, alkalmazási helyzetek. Mit kell és 
mit lehet megváltoztatni a SIF állományokban? Ezekre a kérdésekre keressük a választ a következő részben. 


Farkasokkal táncoló 

Szolgáltatások 

Jobbról is, balról is körbejártuk már a fürtszolgáltatást, szinte minden beállítást ismerünk, csak még erő- 
forrásokat nem hoztunk létre egy szálat sem. A következő fejezetet kizárólag e témának szenteljük. 


SOL Server 

A halálos ölelés 

Az SOL Server belső felépítésének boncolgatása során elérkezünk a zárolási (lock) rendszer ismertetéséhez. Mi 
módon akadályozza meg az SOL Server, hogy párhuzamosan futó tranzakcióink felülírják egymás félkész ada- 
tát? Mi a teendőnk a zárolással kapcsolatban? Hogyan lehet elkerülni a legsúlyosabb esetet, a deadlockot? 


Jogi esetek 

Az Internettörvény 

Internettörvény vagy csak az elektronikus kereskedelem szabályzása? Decemberben elfogadta az Országgyű- 
lés a szakma által korábban csak Internettörvényként emlegetett elektronikus kereskedelmi törvényt. Kará- 
csonyi ajándékként december 24.-én a Magyar Közlönyben meg is jelent a jogszabály szövege. Cikkünk be- 
mutatja, hogy a sok szakmai vitát, egyeztetést megélt törvény mit és hogyan kíván regulázni? 


vörking víith vindoss 7 8002. 043. 
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